search

isaacs / tshy

Other
894 stars 18 forks source link

Node 10 module resolution compatibility #85

Closed thomasballinger closed 4 months ago

thomasballinger commented 4 months ago

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

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.

isaacs commented 4 months ago

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.

thomasballinger commented 4 months ago

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".

thomasballinger commented 4 months ago

Wrote up https://github.com/isaacs/tshy/pull/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.