Is Node 13 & 14/ESM modules support planned soon + is this repo still maintained?

[desmap]

Just deciding if I turn a bigger codebase into ESM modules but tsconfig-paths is the only lib used which doesn't support ESM modules. So if yes, how fast? And is this repo maintained in the first place?

[jonaskello]

This package is mainly for implementing the resolution logic of tsconfig paths so it can be called as an API from other packages as is done in eg. sconfig-paths-webpack-plugin. If you want to use native modules with tsconfig paths I would suggest you try to implement the new hook for resolving native modules and call the API in this package for the resolution logic. If it is successful and proves useful we could integrate it into this package similar to this package has the require hook, or the hook could be kept in it's own package, perhaps something like tsconfig-paths-esm. Note that I have no idea if any of this is possible but if you try it I guess we will find out :-).

One thing to keep in mind when looking into module resolution in newer versions of node might be the new exportsfield in package.json as discussed in this issue.

About maintenance of this package, as I said above the scope of this package is really about implementing the resolution logic as an API so if there is a bug in that part PRs are of course welcome. New features that extends the scope of the package could also be possible but more unlikely as they could be implemented in other packages.

Internally, we have switched most our projects to mono-repos with multiple packages using yarn workspaces (and typescript projects references). For our use cases, this avoids using tsconfig path mappings altogether as we can import the packages in the monorepo by their name using normal node resolution. From what I understand workspaces is also coming to npm. You may want to look into if that fits your use-case. There is now also yarn pnp which may help with resolution issues but I have not tried it yet and I'm not sure how that would work with native modules.

[desmap]

@jonaskello,. thanks for your post and sorry for my late reply.

Internally, we have switched most our projects to mono-repos with multiple packages using yarn workspaces (and typescript projects references)

So, I went this path the last days and first, I thought, this is better but now, yeah IDK. There also some quirks, it's too complex to put it all into one post. However, I tried yarn 2 but struggled with it's lacking esnext modules, guess I need to work around this with esm somehow. Then, it's tricky to create "browser shims", means you have a common lib and the server gets the full lib but the browser code gets just a shim which is path with different code within that same module.

IDK, let me try more and I hope that I have a robust solution soon. ;)