Support module specifiers with extensions in editors

[kitsonk]

Mostly this is for tracking purposes.

Currently the TypeScript language services module specifier resolution does not allow extensions as part of the module specifier. The TypeScript team's main argument is that all the main module loaders (AMD, CommonJS, SystemJS and native browser module loaders) support extensionless module resolution and has been the common standard. Add to that the TypeScript is generally a transpiled language means that a module specifier of foo/bar.ts would need to be rewritten to foo/bar.js or maybe foo/bar.mjs or foo/bar.ejs or anything really after transpilation and rewriting module specifiers is a really loaded and complex topic.

@guybedford indicated that Node.js is considering supporting full extension module resolution. I suspect if that is the case, TypeScript would need to reflect that, but that would complicate what needs to be done at design time and what would be reality at run time. It will simply be complicated.

The other challenge that Deno has, is that even if there was a default module resolution with extensions in TypeScript, it is very unlikely that it would support fetching the types of remote modules for consumption in the editor. So while local modules would have type information, remote one would simply be unresolvable.

The only long term solution I see is that there is a language services plugin for Deno, that would provide a different wrap to the language services API for standard TypeScript, that would do the following things:

• Provide module resolution in line with runtime deno
• Fetch remote module resources and cache them to make their types available to the editor
• Provide the current Deno default type library, so that developers don't have to include it manually

[ry]

Other solution: become popular and force the eco system to support us.
Including the extension is correct as this is how its done in the browser.
So it's their bug, not ours -- they'll come around. I'm not very concerned about this.

[rsp]

@ry Re: forcing the eco system to support us - I already started myself ;) few weeks ago I posted a comment about it in a related issue in the TypeScript repo, just so that people know that the current behaviour and syntax highlighting is completely backwards for some runtimes like Deno - Code highlights good code as error and bad code as ok:

• VS plugin marks import with extension as an error microsoft/TypeScript#11235 (comment)

I'm sure that eventually the editors will support Deno like they support Node today but I'd like it to happen sooner rather than later, so the more people are vocal about it the better.

[guybedford]

FWIW SystemJS 2.0 no longer adds extensions by default to make build tooling adapt to this instead of the other way around.

…

On Thu, 11 Oct 2018 at 09:26, Rafał Pocztarski ***@***.***> wrote: @ry <https://github.com/ry> Re: forcing the eco system to support us - I already started myself ;) few weeks ago I posted a comment about it in a related issue in the TypeScript repo, just so that people know that the current behaviour and syntax highlighting is completely backwards for some runtimes like Deno - Code highlights good code as error and bad code as ok: - microsoft/TypeScript#11235 (comment) <microsoft/TypeScript#11235 (comment)> I'm sure that eventually the editors will support Deno like they support Node today but I'd like it to happen sooner rather than later, so the more people are vocal about it the better. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#920 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAkiyunNTocnbgMYdXBSDVIxqmvD5qPKks5uj3EngaJpZM4XK8wR> .

[rsp]

@guybedford that's good news. I never really understood why transpilers couldn't change the extensions in the first place since they know what they are transpiling anyway (and since import takes a constant string literal so no risk of strings built at runtime, like with require). I am never sure what Node will require with require('./foo') if I have both a directory foo with index.js and foo.js in the same place - add to that multiple extensions to the mix and I'm totally confused.

I see in https://github.com/systemjs/systemjs/blob/2.0.0/docs/system-register.md examples like:

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

so if it's valid in Deno and SystemJS then I guess VS Code and others will follow, hopefully sooner rather than later.

Update: It turns out that VS Code considers js extensions to be fine, only ts extensions to be errors, which is even more confusing than I thought before - see this comment microsoft/TypeScript#11235 (comment)

[kitsonk]

which is even more confusing than I thought before

Well, it is sort of simple from the TypeScript perspective, .ts code isn't ever designed to be run in a runtime, and then when you try to determine what it will be at runtime it get mind-bogglingly complex. So out of the box, I still agree that TypeScript should prevent people from assuming that .ts will be .ts at runtime. What we need is a literal module resolution mode that is a compiler option.

Because we have the extensionless at the moment, and Node.js is considering changing their module resolution, my opinion is we wait a bit longer and if push comes to shove, I suspect we could submit a PR that meets our needs and champion for it with the core TypeScript team.

[bartlomieju]

@kitsonk is this issue somehow resolved with your deno_ls_plugin?

[kitsonk]

Yes and the VScode plugin.