Node 10 module resolution compatibility
Closed this issue · 3 comments
One thing blocking some of my migrations to tshy is wanting "exports" / multiple entry points to work with module resolution algorithms that don't understand "exports":
- Metro without this experimental option enabled
- Some Jest setups? sorry no repro, and I may be out of date there; just some user reports
- really old Node.js (anything before 12, calling is "Node 10" in the title based on the tsconfig.json moduleResolution option)
I use the workaround of directories with a single package.json that points to the dist folder and have homegrown scripts to create these.
Very reasonable not to support this! But making that explicit would be nice, especially since the README is such a font of information. And if you did choose to support it I love to get rid of some hacks.
Literally the entire approach used by this module, including the very idea of building hybrid packages in the first place, depends on the module loader that was introduced in node v12.
There is no way (and no reason) to use tshy if you're targeting a platform that lacks support for it.
Yes, you can simulate something like subpath exports using subfolders with package.json files, but what you can't say is "foo/bar is CJS if you're using require(), and ESM if you're using import", which is the point of tshy existing.
I'd welcome a doc patch indicating very prominently that node 10 is not and will never be supported. (In fact, tshy just dropped support for node 18 in the latest major release.) But it also feels a bit excessive at this point. It's not "experimental", it's been around longer than covid.
To the future present! Thanks for this great tool.
To anybody thinking about this workaround: don't, it's a mess! And if you must it works fine as another script after tshy in "prepare".
Wrote up #86 if you think it's worth it. Makes sense that regardless of who thinks they need this it has no business in this tool.