Skip to content

Feature: disable extensionless imports #28288

Description

@sliekens

I'd like there to be a way to always require the file extension to be specified for relative import statements. At the moment extensionless imports always just work. Even 'Go to Definition' just assumes it should open the JS file.

src/
 - index.js
 - foo.js
// index.js
import { Foo } from './foo'; // extensionless

I'd like there to be a jsconfig option to disable this behavior and require a file extension to be specified.

import { Foo } from './foo';
                    ^^^^^^^ No definition found for 'foo'
// fix
- import { Foo } from './foo';
+ import { Foo } from './foo.js';

I'm asking because extensionless imports don't really work in the browser if you're not using a module bundler. It can only work if the HTTP server supports extensionless imports, which is a big ask.

Activity

  1. removed their assignment
    on Nov 1, 2018
  2. mjbvz commented on Nov 1, 2018

    @mjbvz

    Related: https://github.com/Microsoft/vscode/issues/62401

    This one is specifically about treating extension-less imports as an error, presumably when you are using checkJs

  3. sliekens commented on Nov 1, 2018

    @sliekens
    Author

    presumably when you are using checkJs

    I added a jsconfig.json file to my project and that magically gives me autocomplete in vscode. I was unaware that TypeScript is responsible for JS intellisense.

  4. fatcerberus commented on Nov 10, 2018

    @fatcerberus

    I’m going to put my support behind seeing a fix for this. Browsers support ES modules natively now and TS isn’t a nice experience for web development because:

    1. Automatic imports are added without an extension
    2. Browsers don’t support extensionless imports
    3. TS doesn’t support module specifiers rewriting

    ...which creates a perfect storm in which it’s possible to write several modules with a nontrivial dependency graph before realizing that the whole thing is broken because none of the import statements have extensions. Fixing it is then an exercise in patience as you hunt through the project looking for offending imports—and the browser won’t help you here because it stops short at the first one that fails to load. It’s not a good development experience, which sucks because TS is so, so nice otherwise. :(

    Even if TS just rewrote imports in the generated code to append a .js to any specifiers without it, that would be a good interim solution, I think.

  5. karlprieb commented on Oct 7, 2019

    @karlprieb

    I had the same problem and until the compiler has this option to add .js extensions I migrated to babel and created a babel plugin to add an extension to import modules declaration.

    Here is the plugin if anyone has interest in it: https://www.npmjs.com/package/babel-plugin-add-import-extension

  6. MicahZoltu commented on Oct 8, 2019

    @MicahZoltu

    Karl Prieb (@karlprieb) See https://github.com/Zoltu/typescript-transformer-append-js-extension/ for a TypeScript transformer that adds .js extension to all imports that don't have an extension during compilation. This results in ES that runs in a browser with a static file server (no server-side configuration necessary).

  7. karlprieb commented on Oct 8, 2019

    @karlprieb

    Micah Zoltu (@MicahZoltu) Thank you, Great work!
    I already made all my setup using babel :(
    I created an typescript boilerplate using babel and pika, you can take a look here: https://github.com/karlprieb/typescript-pika-web-starter maybe it can help you if you want to use babel :)

  8. removed
    VS Code PriorityCritical issues that VS Code needs fixed in the current TypeScript milestone
    on Jan 29, 2020
  9. thw0rted commented on Dec 14, 2020

    @thw0rted

    It's weird but I don't think this issue has any links yet to the ur-issue, #16577. Technically, providing a flag to error out is different from providing a flag to append the correct extension, but it's pretty similar.

  10. RyanCavanaugh commented on Mar 4, 2024

    @RyanCavanaugh
    Member

    This is node16 module resolution

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Domain: ES ModulesThe issue relates to import/export style module behaviorIn DiscussionNot yet reached consensusNeeds ProposalThis issue needs a plan that clarifies the finer details of how it could be implemented.SuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions