Add file extensions when auto-completing import paths

[mjbvz]

From @Rich-Harris on October 6, 2017 14:58

• VSCode Version: Code 1.17.0 (be377c0faf7574a59f84940f593a6849f12e4de7, 2017-10-05T06:07:51.906Z)
• OS Version: Darwin x64 16.7.0
• Extensions:

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:

1. Open or create a JavaScript file
2. Start typing import x from './ followed by the name of a sibling file

Reproduces 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

[mjbvz]

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
            }
        }
    }
]

[aluanhaddad]

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.

[mhegazy]

I would like to get more user feedback on this issue.

[shannon]

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.

[Arilas]

Webpack, Browserify, etc support extensionless imports. Browser native import implementation is still something unusable. So I don't agree with this change

[shannon]

@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.

[Rich-Harris]

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.

[nicolasparada]

@shannon It's already on Edge without the flag.

[ghost]

I think we could infer this from existing imports -- if they use .js new imports should too.

[mhegazy]

With #22236 merged (TS 2.9) we can add an explicit configuration for it as well. PRs welcome.