Allow modular use of emit-less types #28
Description
A regular TypeScript compilation takes many modules into consideration at once. It manages imports and exports of types as well as values, where as ECMAScript is only concerned with values. TypeScript only uses the type information of emit-less types like interface
, type
, const enum
etc. during compilation and discards these from the final emit; they simply won't exist in the output.
This poses a problem since Rollup processes modules in the order they're encountered. Any module transforms have to be done without any information about its dependencies (except for some rare cases with circular dependencies). We simply cannot know if an imported identifier is an emit-less type or a value that is preserved. When Rollup later attempts to hook up the imports of one file with the exports of another, it will complain that the imports for these emit-less types don't have any corresponding exports.
Import and use of a const enum
This means that any import and usage of a const enum
defined in another module will fail.
// some-enum.ts
export const enum Foo { bar, baz } // results in the empty string after transpilation
// main.ts
import { Foo } from './some-enum';
// Rollup -> Error: Module some-enum.ts does not export Foo (imported by main.ts)
console.log( Foo.bar );
What we would want is for the import
statement above to be completely removed since no actual value is imported, and for Foo.bar
to be replaced with the constant value it corresponds to.
Re-export of an emit-less type
A re-export of a type will fail since the module doing the re-export cannot know that what is being exported doesn't exist except during compilation.
export { Foo } from './some-enum';
// Rollup -> Error: 'Foo' is not exported by 'some-enum.ts' (imported by main.ts)
In this case, we'd just like the export
statement to be removed.
Summary
To be useful in practice the plugin must gracefully handle:
- imports and usages of
const enum
s defined in other modules - re-exports of emit-less types
These problems can only be solved by having TypeScript process several modules simultaneously. Unfortunately, this doesn't fit well with Rollup's current behaviour of processing modules in turn as they're encountered.
Hopefully someone might be able to bring some good insights as to how to solve this problem.