Module imports need to recognize/ignore the file extension

[weswigham]

Currently, TS can't find modules when you use a file extension in the import name (import {Foo} from './foo.ts';) - SystemJS updated and file extensions are now required (though the spec issue is still under discussion) on imports (without setting some legacy settings in System.config). So when compiling with --module, you can either have a functioning typechecker (no extensions on your imports) or a functioning runtime (.js on your imports, since your result files have .js extensions). This is complicated further by systemjs's bundler, which looks for dependent files before TS transpiles them, so you have to use .ts extensions on your imports so the bundler can resolve the paths to real ones.

This extension madness is all incredibly awkward to work with, and I'm not sure if this needs module resolution logic updating on our part, arguing for old behavior on the loader spec, or talking to systemjs and having them change how they're finding modules ignoring the spec.

[kitsonk]

I hate to say this (and having read through the thread you linked to) that is madness. Are TC39 going to seriously consider adopting that? My initial reaction is now is the time to abandon SystemJS before it gets too late. I think @jrburke tried (sadly fruitlessly) to explain why that approach is going to cause all sorts of problems. Transpilation (and ergo TypeScript) are already going to suffer from this now. There is a very good reason why the MID should be decoupled from the actual physical filesystem/URI. As you are pointing out, bundling and build optimisation, transpilation, etc can make a MID with an extension something totally inane.

This also throws up whole issues with those of us using CommonJS/AMD/UMD. TypeScript is going to have to try to start trying to rewrite MIDs based on the packaging target...

My advice would be to wait at least to see what comes out of TC39 in regards to this. If that gets adopted then, it gets adopted and we all have to deal with it. Does anyone know what the plan with TC39 is?

[jrburke]

My understanding is that the loader spec will be setting the constraints around module ID resolution. Since that is a whatwg repo, it is not something that is specifically under the TC39 umbrella, but as far as I know the people authoring the spec are TC39 members.

If you wanted to discuss with them, opening tickets in the whatwg loader repo seems to be the main channel, although response times by authors can be long. I have also asked if I could help or offered to talk through issues offline, but those did not receive responses. It seems they prefer to consult among themselves as they feel they have the most global context, and perhaps browser implementers, before engaging more with others outside of that core.

I am unsubscribing from this issue, so may not see further updates.

[IgorMinar]

Have you considered accepting imports authored without .ts extension and emitting imports with .js extension?

With this setup, the systemjs bundler could then be fed es6 code which already contains imports with the extension and things would "just work".

I don't quite understand the reasoning behind these recent loader spec/systemjs changes despite reading quite a bit about it. For application code it makes sense to make the imports environment specific (except for the extension which changes with transpilation), but for 3rd party code, I'd expect the imports to be portable so that I can easily switch between local development friendly copy of the lib and a production, minified, and/or cdn hosted version of it without changing any imports in my code.

[IgorMinar]

related SystemJS issue: systemjs/systemjs#756

[frankwallis]

TypeScript 1.6.0-beta now supports overriding the built in module resolver as per this issue. I have implemented this in plugin-typescript so that it uses the systemjs resolution logic which means you can currently import files with or without the .ts extension.

I agree with @IgorMinar that having TypeScript change the file extensions when compiling may be the best way to support this, but for that I think that SystemJS would need to provide a way for loaders to change the extensions of the files as they move through the pipeline. It does seem odd that currently after compilation you have .ts files in the registry which have been converted to JavaScript.