Repository navigation
--module=ES2016 should re-write "index" imports #12597
Description
TypeScript allows shorthand for importing the index.ts file in a package. CommonJS does too.
However, this is not specified in ES2015 modules. Some loaders/bundlers support it (Rollup, Webpack) but some do not (Closure Compiler)
It would be more conservative to normalize these import locations to include the explicit /index suffix for better compatibility.
Repro:
$ ./node_modules/.bin/tsc -v
Version 2.0.10
$ cat import_index.ts
import {a} from './one';
console.log(a);
$ cat one/index.ts
export const a = 1;
$ cat tsconfig.json
{
"compilerOptions": {
"target": "es5",
"experimentalDecorators": true,
"noImplicitAny": true,
"strictNullChecks": true,
"moduleResolution": "node",
"module": "es6",
"rootDir": "",
"declaration": true,
"lib": ["es6", "dom"],
"baseUrl": ".",
"types": []
},
"files": ["import_index.ts",
"node_modules/@types/node/index.d.ts"]
}
$ ./node_modules/.bin/tsc
$ cat import_index.js
import { a } from './one';
console.log(a);
The proposal is this should have been written as import { a } from './one/index';
Activity
aluanhaddad commentedon Dec 1, 2016
Just my 2 cents, and I do not mean to be rude, but I think people should stop using this pattern. It can be ambiguous, it is not supported by the emerging loader specification or SystemJS which seeks to model it, and it is not an obviously great pattern. It is more of a node convention. The other reason to avoid it is that it could well change the meaning of existing code.
evmar commentedon Dec 1, 2016
Aluan Haddad (@aluanhaddad) I also really dislike it, but unfortunately we're trying to support the language that TS supports.
Adam Klein (@ajklein) What's the status on browsers supporting these sorts of imports?
mhegazy commentedon Dec 1, 2016
The position we have taken is that module identifiers are strings that users wrote, and we do not mess up with them. no rewriting, no fixing. whatever you write there will be in the output.
The compiler should be able to handle you setting a full path in your import. e.g.
import { a } from './one/index.js';if you so choose. it will still know that you mean to import the ts file./one/index.ts.We could add a new module resolution strategy, call it ES2015 that does not do the extra node resolution steps for packages. and thus give you an error if you try to import
.\one\index.jsthrough.\one, but that can be achieved today by a tslint rule that says all imports need to have a.jsextension at the end.alexeagle commentedon Dec 1, 2016
mhegazy commentedon Dec 1, 2016
module systems have different semantics when it comes to module names. for instance loder extensions. they have different syntax between AMD, and SystemJS for instance (
json!./resourcevs./resource!json). other things related to configurations, and the underlying module system.Some webpack extensions rewrite module names, and babel extensions that rewrite module names. Add JSPM on top and you have a whole new beast. and the list goes on..
the whole module resolution philosophy here is, you have some JS code that works with some tool. the compiler does not need to understand what it is, or where it comes from, all it needs is to know where to find a declaration file for it. hence the ambient module declaration (
declare module "blah" ...) construct.Doing this correctly all the way, will need the compiler to always understand what you are writing in the module name as a file location (something we do not do today), moreover, it breaks the single file emit case, where the compiler does no resolution or locating of files on disk.
ajklein commentedon Dec 2, 2016
Looping in Domenic Denicola (@domenic) to help answer Evan Martin (@evmar)'s question about browser support for this kind of resolution, as I know he's been involved in some design work in this area.
alexeagle commentedon Aug 10, 2017
note: closure compiler added
--module_resolution=nodewhich supports implicit import from/indexso we don't need the workaround anymore.