Becoming a maintainer

[cspotcode]

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?

[jonaskello]

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 :-)

[cspotcode]

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.