Typescript: Add file extensions when auto-completing import paths

Created on 8 Oct 2017  Â·  10Comments  Â·  Source: microsoft/TypeScript

_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_

Completion Lists Fixed Suggestion VS Code Tracked

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.

All 10 comments

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.

Was this page helpful?
0 / 5 - 0 ratings