Closed cspotcode closed 4 years ago
Your help is very welcome : -). This project actually started as a PR for ts-node in this issue.
Regarding the new ESM support I'm not sure tsc
itself supports it yet. I've been monitoring this issue. I'm not sure we should extend this package beyond what tsc
supports but of course this support will come sooner or later. I've also been considering splitting this package into two packages. One that has the pure resolution algorithm and one that has the hooks for require etc. The main package that depends on this package is tsconfig-paths-webpack-plugin
and it only use the algorithm parts, not the hooks. Not sure if it would make sense or not to split it.
Anyway I'll make you a maintainer and we can discuss in other issues :-)
Excellent, thank you.
Regarding ESM support, I was specifically thinking of this issue filed today: #133
The author was originally trying to debug the issue in ts-node's issue tracker but eventually tracked it down to tsconfig-paths. The affected module has 2 entrypoints: index.js and index.cjs. It looks like tsconfig-paths was somehow resolving to the wrong one. This led me to suspect, without concrete evidence, that tsconfig-paths needs to be updated to understand package.json "exports"
and "module"
fields. The affected module isn't using TypeScript and doesn't need to be transpiled, but I guess tsconfig-paths was trying to handle resolution anyway due to the weird baseUrl.
ts-node
already implements a loader hook, so I think we'll need some sort of integration so that our loader hook supports "pluggable" resolution, allowing tsconfig-paths to resolve certain imports.
I've been getting bug reports on ts-node that turn out to be bugs in tsconfig-paths. And it looks like this project could use some help dealing with bugs and updating for node's new ESM support. Can I become a maintainer?