_From @Rich-Harris on October 6, 2017 14:58_
Extension|Author (truncated)|Version
---|---|---
Handlebars|and|0.2.0
vscode-eslint|dba|1.3.2
prettier-vscode|esb|0.24.0
vscode-import-cost|wix|2.5.0
Steps to Reproduce:
import x from './ followed by the name of a sibling fileReproduces without extensions: Yes
When you start writing a local import statement, the intellisense helper will offer up foo and bar rather than foo.js and bar.js. Extensionless imports is a Node idiom that is incompatible with browser module loaders — adding the file extension would increase browser compatibility with no ill-effect on Node apps (to the contrary, it speeds up module resolution, and I'd argue it makes code more explicit and readable).
I wonder if you would consider changing the behaviour to add file extensions by default?
_Copied from original issue: Microsoft/vscode#35730_
Here's the completions information currently returned for a file x.ts:
[Trace - 07:59:41] Response received: completions (132). Request took 2 ms. Success: true
Result: [
{
"name": "x",
"kind": "script",
"kindModifiers": "",
"sortText": "x",
"replacementSpan": {
"start": {
"line": 1,
"offset": 27
},
"end": {
"line": 1,
"offset": 27
}
}
}
]
If the behavior is changed, the ability to restore the old extensionless behavior should be made available via configuration.
Also this is not simply a Node.js convention but is used by a number of module loaders such as RequireJS.
I would like to get more user feedback on this issue.
I ran into this when using the new auto import functionality. Not including the extension makes it invalid for browsers, while including the extension does not make it invalid for Node/RequireJS. It would be nice if it was configurable one way or the other though.
Webpack, Browserify, etc support extensionless imports. Browser native import implementation is still something unusable. So I don't agree with this change
@Arilas it's usable in Chrome and Safari by default now. In Edge and Firefox it's behind a flag but this is now the standard so it should at least be configurable to use the standard.
Just to reiterate, the choice isn't between Node compatibility and browser compatibility, it's between Node compatibility and (Node + browser) compatibility. Nothing would break — it would just result in faster and more explicit code.
@shannon It's already on Edge without the flag.
I think we could infer this from existing imports -- if they use .js new imports should too.
With https://github.com/Microsoft/TypeScript/pull/22236 merged (TS 2.9) we can add an explicit configuration for it as well. PRs welcome.
Most helpful comment
Just to reiterate, the choice isn't between Node compatibility and browser compatibility, it's between Node compatibility and (Node + browser) compatibility. Nothing would break — it would just result in faster and more explicit code.