VS plugin marks import with extension as an error

[outring]

According to the #4595, file extensions are now allowed to be present in imports, but it's still highlighted as an error by IntelliSense.

TypeScript Version: 2.0.3.0

Code

import {foo} from "./bar.ts";
import {foo2} from "./bar2.tsx";

Expected behavior: No "An import path cannot end with a '.ts' extension" error

Actual behavior: "An import path cannot end with a '.ts' extension" error

[outring]

I've read #9538 and it seems that you disallowed it intentionally, but what's your proposition of using TS with system.js since they permitted omitting the extension, as stated in #4595? And especially when you need to distinguish *.ts and *.tsx, no defaultExtension option for system.js will help :(

[mhegazy]

According to the #4595, file extensions are now allowed to be present in imports, but it's still highlighted as an error by IntelliSense.

output file extensions are allowed. i.e. ./bar.js. One thing to note is that the compile will not change your module name. so if you write import ... from "./bar.js" the output will be require("./bar.js"). So since the .ts files do not exist at runtime, importing ./bar.ts is going to fail, and thus is flagged as an error.

[outring]

Hi, @mhegazy. When using system.js all compilation could work right in the browser, this is what plugin-typescript does. So you need to be able to load actual .ts/.tsx files. It's simplifies everything a lot: you don't need to precompile anything — it just works.
The same way work all other loader plugins for system.js, like css, sass and so on — you just need to be able to specify exact url for the file.

[outring]

I understand that it made to prevent some confusion. Since it's only the system.js (I guess) requirement/feature, so probably such behavior should be allowed when module format is set to system.js only

[mhegazy]

SystemJs has support for defaultExtension, is not that sufficient here?

[outring]

Even if it works, we still need to distinguish *.ts and *.tsx

[glebmachine]

Still got this error

[aluanhaddad]

@glebmachine why not use

packages: {
  "app": {
    "defaultExtension": "ts"
  }
}

If you have tsx and ts files in the same directory, you can either split them into different directories, setting different default extensions, or you can change the ts files to tsx files.

[asdacap]

I have the same issue with the VSC plugin. I'm using webpack with ts-loader, so (AFAIK) the extension is required because of the loader extension test. If I remove the extension, webpack crash with 'cannot find file' error, if I add the extension, VSC shows a red line and no intellisence for that module.

[aluanhaddad]

No it is not required. Stop using it.

[aluanhaddad]

systemjs+/- jspm with typescript

webpack with typescript via ts-loader
webpack with typescript via awesome-typescript-loader

[asdacap]

Sorry, my bad. Did not include the resolve.extensions configuration.

[molszanski]

@aluanhaddad

No it is not required. Stop using it.

It is not required, but there are arguments for using it.

Ryan Dahl, the creator of Node.js lists this implicit extension resolution as one of his biggest regrets about Node.js and the impact it made on the ecosystem.

YouTube link
Slides

[oldrich-s]

I completely agree with @molszanski and Ryan Dahl on that.

Interestingly, importing mts works just fine:

import * as X from './test.mts'

which is what Google recommends:

https://developers.google.com/web/fundamentals/primers/modules

Still, we recommend using the .mjs extension for modules, for two reasons...

So probably we should use .mts instead of .ts ;).

[molszanski]

At least it should possible.

[ashnur]

No it is not required. Stop using it.

@aluanhaddad Can I make it required? I really want to use explicit extensions, as otherwise my brain just thinks it's a folder/directory. Really hard to read source that depends on black magic with dozens of algorithmic steps to find the appropriate source that should be imported...

[molszanski]

I think we need a new thread. It looks like nobody is really reading closed threads sad.

[ashnur]

@molszanski you do it or I do it? :) I need to read up more on this to be able to open a proper issue that will not be automatically closed, and that might take a while...

[molszanski]

@ashnur, I've added it to my todo list. If don't make it in 2 weeks, please step in :)

[rsp]

@molszanski @ashnur Any updates on that issue?

Currently, when using VSCode to write Deno code, the error indication is completely backward.

You can either have:

1. No error in the editor and a broken code:

2. Error in the editor and a working code:

It would be useful to have a configuration flag to make the extension required and show an error if it's missing (because it is indeed required in some environments, like e.g. Deno) but at the very least it should be possible to not mark valid code as an error.

By the way, Deno doesn't write .js files for the .ts files so the argument that having the extension in import paths will break the transpilation is not relevant. Full file names in imports are always required in Deno, it will never try to guess missing parts of file names (as it shouldn't, in my opinion - I think that full names should be used in imports and every transpiler should change them if needed, but that's beside the point).

[ashnur]

I am inherently and completely befuddled by this situation.

[ilpoo]

An additional note on Deno: the .mts extension trick isn't a valid solution either, as it's an unsupported file type in Deno. You absolutely have to write .ts if you want the code to run.

And if you just choose to ignore the error, you don't get intellisense:

[rsp]

See also the docs of SystemJS 2.0
https://github.com/systemjs/systemjs/blob/2.0.0/docs/system-register.md

The code examples look like this:

a.js

import {b} from './b.js';
export function a() {
  b();
}

b.js

import {a} from './a.js';
export function b() {
  console.log('b');
}
a();

But interestingly enough, in VS Code this is fine:

But this isn't:

Giving:

[ts] An import path cannot end with a '.ts' extension. Consider importing './b' instead.

I didn't expect that to be honest, I thought that if it considers import {x} from './b.ts'; to be an error it will do the same with import {x} from './b.js'; as well. 🤔

[jgierer12]

Any updates on this? I'm also trying to write Deno code, it's really disappointing that such a seemingly minor issue is breaking integration between Deno and VSCode.

[ashnur]

I know I promised, but I gave up on TypeScript. It just doesn't worth the time investment for me, I do not see the benefits of it anywhere in practice beyond what people say ... and people say lots of things.

[ryancwalsh]

I'm confused about why this issue is closed.

I agree with #11235 (comment); it seems that people trying to write TypeScript in VSC face this dilemma of choosing between:

1. VSC shows an error (red underline), but the code works, or:
2. If we follow the VSC error tooltip's suggestion, it will "resolve" the error in the editor, but then the code won't run.

[molszanski]

@ryancwalsh, I suggest a new issue

[ryancwalsh]

@molszanski I submitted a bug report to the "vscode" repo here: microsoft/vscode#108872