-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Comments
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 :( |
output file extensions are allowed. i.e. |
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. |
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 |
SystemJs has support for |
Even if it works, we still need to distinguish *.ts and *.tsx |
Still got this error |
@glebmachine why not use packages: {
"app": {
"defaultExtension": "ts"
}
} If you have |
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. |
No it is not required. Stop using it. |
Sorry, my bad. Did not include the |
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. |
I completely agree with @molszanski and Ryan Dahl on that. Interestingly, importing
which is what Google recommends: https://developers.google.com/web/fundamentals/primers/modules
So probably we should use |
At least it should possible. |
@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 think we need a new thread. It looks like nobody is really reading closed threads sad. |
@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... |
@ashnur, I've added it to my todo list. If don't make it in 2 weeks, please step in :) |
@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). |
I am inherently and completely befuddled by this situation. |
See also the docs of SystemJS 2.0 The code examples look like this: a.js
b.js
But interestingly enough, in VS Code this is fine: But this isn't:
I didn't expect that to be honest, I thought that if it considers |
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. |
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. |
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:
|
@ryancwalsh, I suggest a new issue |
@molszanski I submitted a bug report to the "vscode" repo here: microsoft/vscode#108872 |
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
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
The text was updated successfully, but these errors were encountered: