Support for TypeScript files about import-meta-resolve HOT 13 CLOSED

Does the built-in Node.js import.meta.resolve correctly resolve them, or does it throw?

from import-meta-resolve.

Here's the reproduction https://github.com/ifiokjr/import-meta-resolve-ts

import.meta.resolve does correctly resolve TypeScript files.

from import-meta-resolve.

Can you make a small reproduction?

I did indeed notice the introduction of the error when I ported the code back two weeks ago, and checked that it’s thrown for a file such as readme.md, which I guess makes sense. Not sure if its intentional for these files though.

from import-meta-resolve.

Thinking beyond my short-term needs, it probably makes sense to remove the extension restrictions.

There are many file extensions which can legitimately be resolved. .wasm and .node spring to mind. There's even a case for allowing .md, .css etc... to be resolved as they can be loaded and used in the context of the code resolving the file path.

Would it make sense to remove the file extension restriction entirely?

from import-meta-resolve.

I don’t think so. Node has that map for some reason. But it doesn’t fail on this case. We also have that map, but it fails. The problem is not that there is a map. The problem is the divergence from Node

from import-meta-resolve.

@wooorm I also expected it work, especially when using a TypeScript specific loader like ts-node.

If index.ts attempts to resolve ./foo.ts, then it will work with import.meta.resolve and not this package.

node --loader=ts-node/esm index.ts

from import-meta-resolve.

This issue is solved.

from import-meta-resolve.

I still face the similar issue with the latest version. Lemme try to share a reproduction repo

from import-meta-resolve.

Here you go. https://github.com/thetutlage/imr-issue

I see the issue is when the file has .js extension. However, TypeScript forces using .js file extension for TypeScript files as well. So it cannot be changed to .ts

from import-meta-resolve.

You are talking about loaders. Unrelated to this issue. More related to #10.
Loaders are implemented above this function: #10 (comment). They require tons of extra code to implement. But they can’t even be implemented: they’d require CLI arguments. You’d have to pass {loader: 'ts-node/esm'} to import-meta-resolve. But that’s a different API from resolve.

If you are going to use experimental APIs (loaders), you can just as well use import.meta.resolve itself?

from import-meta-resolve.

Thanks for explaining!

Maybe, I had a wrong expectations from the package. I thought it is a drop-in polyfill for import.meta.resolve and addresses the use case where loaders take over the import URLs and resolve them.

But, it is fine, if you think that this use case is out of scope of this package. I just wanted to highlight my use case :)

from import-meta-resolve.

For your second paragraph: take a look at the readme, the differences section, I guess loader can be added there in the CLI flags (if it isn't already) But that gives an indication of how giant the scope of Node is! I think by the point all those flags are implemented, you almost have a copy of Node!

I think it would be cool to have some of these, particularly loaders, but that would probably be a new optional API (as CLI args have to be parsed, so it has to be Node that's executed from the CLI). And it would likely be a lot of work, which I'm not interested in currently doing

from import-meta-resolve.

Yup, makes sense! Also, for a while (until it is experimental), the resolve API will be a moving target, so it might be wiser to cherry pick which features are worth implementing.

Anyways, thanks for your time :)

from import-meta-resolve.