Recursively resolve typescript types

[timsuchanek]

I expect the output of ncc to be runnable without npm dependencies. However, if I have a type that is included from another library, I need to keep that library as a dependency and the types are not resolved. So an import is not being resolved and the output of ncc looks like this:

import { Type } from 'library'

As this is already the behavior of the code bundling with Webpack, I would expect this to work with TypeScript, too.

In other words we need a Webpack for typings.

This could e.g. be done with https://www.npmjs.com/package/declaration-bundler-webpack-plugin

[styfle]

However, if I have a type that is included from another library, I need to keep that library as a dependency and the types are not resolved.

I don't understand this use case. When you compile your code with tsc (or ncc in this case), the types are erased and only JS is available at runtime. I don't see a scenario where the TS types are necessary at runtime.

Can you create a small example that works properly with tsc && node index.js but fails with ncc run index.ts?

[jasonkuhrt]

I don't see a scenario where the TS types are necessary at runtime.

What if the output of ncc is a library intended to be consumed by other TypeScript projects?

[alexandernanberg]

At work we currently have a shared lib for CDK templates etc

// index.ts
import * as cdk from '@aws-cdk/core';
import * as constants from './constants';
import * as stacks from './stacks';
import * as templates from './templates';

export { cdk, constants, stacks, templates };

Everything works, but consumers of the lib won't get any types for the cdk export. Haven't found a workaround for this yet