Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VS plugin marks import with extension as an error #11235

Closed
outring opened this issue Sep 29, 2016 · 28 comments
Closed

VS plugin marks import with extension as an error #11235

outring opened this issue Sep 29, 2016 · 28 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@outring
Copy link

outring commented Sep 29, 2016

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
Copy link
Author

outring commented Sep 29, 2016

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
Copy link
Contributor

mhegazy commented Sep 29, 2016

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.

@mhegazy mhegazy added the Working as Intended The behavior described is the intended behavior; this is not a bug label Sep 29, 2016
@outring
Copy link
Author

outring commented Sep 29, 2016

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
Copy link
Author

outring commented Sep 29, 2016

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
Copy link
Contributor

mhegazy commented Sep 29, 2016

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

@outring
Copy link
Author

outring commented Sep 30, 2016

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

@glebmachine
Copy link

Still got this error

@aluanhaddad
Copy link
Contributor

@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
Copy link

asdacap commented Jan 10, 2017

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
Copy link
Contributor

No it is not required. Stop using it.

@asdacap
Copy link

asdacap commented Jan 10, 2017

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

@molszanski
Copy link

@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
Copy link

oldrich-s commented Jun 26, 2018

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
Copy link

At least it should possible.

@ashnur
Copy link

ashnur commented Sep 19, 2018

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
Copy link

molszanski commented Sep 19, 2018

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

@ashnur
Copy link

ashnur commented Sep 19, 2018

@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
Copy link

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

@rsp
Copy link

rsp commented Sep 27, 2018

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

screen shot 2018-09-27 at 1 55 14 pm

2. Error in the editor and a working code:

screen shot 2018-09-27 at 1 55 38 pm

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
Copy link

ashnur commented Sep 27, 2018

I am inherently and completely befuddled by this situation.

@ilpoo
Copy link

ilpoo commented Oct 10, 2018

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:
image
image

@rsp
Copy link

rsp commented Oct 12, 2018

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:

screen shot 2018-10-12 at 4 09 51 pm

But this isn't:

screen shot 2018-10-12 at 4 09 39 pm
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
Copy link

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
Copy link

ashnur commented Jan 12, 2019

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
Copy link

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
Copy link

@ryancwalsh, I suggest a new issue

@ryancwalsh
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests