TypeScript: VS plugin marks import with extension as an error

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

No it is not required. Stop using it.

@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

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.

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.

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…

I am inherently and completely befuddled by this situation.

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:

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

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 I submitted a bug report to the “vscode” repo here: https://github.com/microsoft/vscode/issues/108872

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

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

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.

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 😦

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