Typescript: IIFE Bundle Type for --module (similar to rollup)

[whaaaley]

Search Terms

iife, module, bundle, format, rollup

Suggestion

A module type iife, only to be used with --outFile (similar to AMD and System), that outputs a bundle similar to Rollup.

Use Cases

Currently I have to compile TypeScript to a tmp directory and then run Rollup over that tmp directory to output an IIFE bundle. If TypeScript had this module type then I wouldn't need Rollup.

_IIFE bundles are simpler and smaller than AMD and SystemJS module types._

Examples

The current use case would replace the following...

tsc --allowJs --module ES6 --sourceMap --target ES5 --outDir tmp src/app.js \
&& rollup tmp/app.js --config --sourcemap --file public/app.js

...and then could simply become this instead

tsc --allowJs --module IIFE --sourceMap --target ES5 --outFile public/app.js src/app.js

Checklist

My suggestion meets these guidelines:

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

[nmain]

This seems to run afoul of one of the stated non-goals:

Provide an end-to-end build pipeline. Instead, make the system extensible so that external tools can use the compiler for more complex build workflows.

outFile is a much simpler situation; once each individual module has been transpiled to amd or system.js, you can just concatenate them and that will just do what is wanted, with the module loader doing a lot of the "work" at runtime.

But packaging the whole thing into a single iffey means a lot more complexity and work for typescript: Names will have to be mangled to not collide, library dependencies need to be parsed and understood, something needs to be done with circular dependencies, etc.

[whaaaley]

@nmain By using AMD and System module systems, they introduce a lot of extra code that doesn't benefit certain use cases, such as small apps and widgets that don't need async module loading. IIFE modules fit that use case much better. I wouldn't consider IIFE module output to be a "complex build workflow", at least personally, but I understand how it might deviate from the mentioned non-goal.

[RyanCavanaugh]

Rollup is 20,000 lines of well-implemented JavaScript that we'd rather not copy for the sake of slightly simplifying something that already works today

[whaaaley]

Rollup is a larger project because does much more than JUST bundling. It has a plugin system, tree-shaking, file watching, a CLI, and exports to multiple module systems, including AMD, CommonJS, and IIFE. What I'm suggesting is only the IIFE module type. If you look at the output of an IIFE bundle, there's not much to it. It's mostly concatenating files and renaming clashes. There's arguably less transformations happening with IIFE than with AMD or SystemJS module types.

Perhaps I shouldn't have mentioned Rollup in the original issue. The benefit here is that you get a much smaller bundle without any other projects in the pipeline. Whether it be Rollup, Webpack, or something else. The TypeScript compiler, as far as bundling goes, is not of much use by itself. I'm assuming that's why AMD and SystemJS module types were added. I wouldn't say IIFE bundles are any more out of scope than the already existing module types.

[kitsonk]

AMD and SystemJS modules were contactable and for various reasons TypeScript emitted both the module formats already, so it was as close to a 0 cost change and ability to maintain and support, even though it contravened the design goals.

An IIFE is more than concatenating files and renaming clashes. You have to deal with default exports and imports, namespace imports, named imports, etc.