Cannot resolve module without extension defined

[Drag13]

Hi guys! First of all let me say big thanks for all the job you already done! Deno looks extremely promising even before release.

Right now I am trying to get a bit more familiar with it and just spotted some kind of issue (I think this is issue but may be I am wrong) when importing my own typescript module.

Let's say we have this code

import { Timer } from "./serivce";
const id = new Timer().start();

It looks OK, but Deno will refuse to run it because it expects to see extension of the file:

Uncaught NotFound: Cannot resolve module "./serivce"

If I will change statement to use extension, as Deno expect, two bad things happens.

• VsCode starts showing next error:
  

• No IntelliSense provided because Timer starts to be "any" - typed

The first issue can be partially fixed using //@ts-ignore. But then, I have to add this every time, and that's a bit annoying. And the second issue seems not fixable for me (again, may be just not found the solution)

So my question: Is it possible to make Deno and Ts more friendly and get rid of this //@ts-ignore?

[bartlomieju]

Using explicit .ts extension is required in Deno.

For some reference with VS Code check this sources:

• https://medium.com/@kitsonk/develop-with-deno-and-visual-studio-code-225ce7c5b1ba
• https://github.com/justjavac/vscode-deno

[Drag13]

Yes, I know that Deno requires implicit extension (I wrote about that), but this cause some problems I've listed before. So is there is there are any plans to harmonize Deno and "common import" to avoid workarounds?

And thank you very much for the provided links!

[kitsonk]

So is there is there are any plans to harmonize Deno and "common import" to avoid workarounds?

What do you mean by "common import". Most browsers require ES modules to include their extension. Node.js has also gone down that path for their support for ES modules.

Also see #2329. We tried it, it made things a lot more complicated, and so we removed it. It is very intentional at the moment to keep it out.

[Drag13]

@kitsonk, please don't get me wrong. I am not trying to blame or force someone. I am just trying to understand current concept and your answer with reference is perfect in this meaning.
Thanks, I'll close the issue.

[ry]

Maybe we can have a better error message when extensions are omitted? Or maybe we should add some text to the manual explaining the situation and our plans with import specifier extensions.

[Drag13]

From my point of view, main problem is that those who use VsCode (like me) get used auto import. And when you are trying Deno - it fails. Adding extension explicitly doesn't help much because than it start failing in another way. So, main question appears:

If I can't use my everyday tool, maybe Deno is not ready yet?

At this moment some explanation (and links posted above especially) will be extremely helpful, because in real life Deno is awesome! But mentioned scenario may stop many and many people from using it. Another point is that, if I already have project - I can't start using Deno, because I have to update imports manually. And after that I can't switch back, because I need to update imports again. This is also kind a stopper.

So, message with explanation and possible solution will be nice (and much better than current). But altering importing mechanism may be a good option also.

Sorry for such long text.

[ry]

Deno is certainly not ready: https://deno.land/manual.html#disclaimer

I think this is the most mature vscode plugin - https://github.com/justjavac/vscode-deno - does that not solve the problem?

But mentioned scenario may stop many and many people from using it

Yep. We have certain design goals that we don't want to compromise for short-term fixes. It's important to get our core infrastructure working as intended ... making a smooth transition for people with existing software is something that will be considered later once we don't have critical bugs. Some things just take time. I appreciate you taking the effort to communicate where it went wrong for you - that's important information for us to know.

[Drag13]

Deno is certainly not ready

Not ready for Prod? Yes, certainly. Not ready for pet projects, every day scripts, experiments, PoC? I think it's good point to start with Deno.

Extension solve problem partially - I still can't transfer code from Node to Deno and vice versa. But it's more-less OK for me, so I can say that my problem solved.

[jpike88]

Ok this to me seems a little odd.

What's the point of ingesting TS files if there's a fundamental, breaking difference in syntax? Are they still 'TypeScript' files at that point? Every person who wants to use Deno will have to do some weird tweak with their codebase and dev tooling that deviates from standard VSCode configuration, breaking existing compatibility with TS (Which means an independent type check on CI for example wouldn't work)...

It would be a tiny amount of code that attempts to resolve a path if there's no extension, at a guess.

if (noExtension) {
    try {
        return attemptTs() || attemptJs();
    } catch (error) {
        throw new Error('No module found here.')
    }
}

This will open up Deno properly to the existing TS community. Deno will benefit from increased usage, attracting more contributors, and at any point you can deprecate that functionality with little effort?

Yep. We have certain design goals that we don't want to compromise for short-term fixes

I don't think this would be a short-term fix, rather a long-term strategy which takes into account high uncertainty in it being resolved anytime soon. Looks like the TS team is not even considering modifying how they resolve paths at this point.

microsoft/TypeScript#27481

[kitsonk]

What's the point of ingesting TS files if there's a fundamental, breaking difference in syntax?

The module specifier is not part of the syntax of the language, and isn't actually specified anywhere. TypeScript will eventually remove the warning or provide a flag that allows it. The world is going the ways of fully specified path names because the extension resolution "magic" has caused so many problems.

Looks like the TS team is not even considering modifying how they resolve paths at this point.

I disagree, both Ry and I have had some conversations with the team. It is something they are going to have to tackle with the way Node.js has gone as well. We will continue to work with them as time goes on. Doesn't mean we always agree though, but I can assure you they haven't closed the door.

[jpike88]

TypeScript will eventually remove the warning or provide a flag that allows it.

We will continue to work with them as time goes on

I mean, I get the sentiment here.

But if deno relies on TS projects, shouldn't it be tracking current TS capabilities? Unless you guys are willing to wait it out... but I would have figured getting it more exposure sooner is a better move? This would be a backwards compatibility thing that you could deprecate when it happens.

But when would that be? End of year? Maybe later?

[kitsonk]

We aren't looking for exposure or more than we already have. The Deno repo has 35k likes. It is already at times like riding a bull. Not that peoples contributions are invaluable, but on this particular point we tried it (#857 and look at who raised the issue 😬 ). Especially when it came to remote modules, it was a horrible waste "guessing" at what the extension might be. Especially with the goal of having both JS and TS supported, it means extension-less is 2-3 full return network requests for each module before you can proceed with the analysis of the dependency graph. So when we saw the reality of our decision, we reverted and realised that "magic" module resolution is actually really bad.

I suspect the reality of getting tsc to support fully qualified extensions and a literal resolution mode is contributing something back to the TypeScript. I haven't taken a look in a while of what it would take to deliver a "literal" module resolution mode, but maybe I should again.

[kitsonk]

Also, I should mention that I think in the long term, to boost adoption, a CDN that would fetch and cache other modules and rewrite them to be fully qualified would be a possibility. Things like Pika CDN already provide ESM bundles transpiled and don't include polyfills for modern browsers. We wouldn't be talking about something too different here.