Importing non-default export of "toString" as default in some plugins causes webpack errors about parse-latin HOT 10 CLOSED

TypeScript isn’t 100% there yet on ESM either, so that might be related.

I’m moving through my projects again, updating deps and adding strict types, so I’ll soon get to updating this one as well anyway!

from parse-latin.

Bundlers are very good at this. They're not confused. They are meant to deal with dependencies with different versions. Different versions isn't a problem.

For your last point, well, the problem is in the bundler. If you're using TS, that's means the problem is TS. The problems isn't nesecarily solved by updating, as your bundler still has problems with other projects using CJS in this way (which, again, is fine), but the problem is side-stepped: both packages are ESM.

from parse-latin.

The problem you describe is not the problem.

This package uses nlcst-to-string version 2, which was CommonJS. And used module.exports.

Are you on the latest webpack 5? Have configured it to support ESM properly?

from parse-latin.

Thanks for your quick reply.

I'm on webpack 5.61.0. That webpack pipeline is configured for ES modules, which load fine, except for the above.

I could only make it work by using the exports-loader webpack plugin, which basically does the first fix suggested above on the fly.

I should mention that this is a standalone TypeScript project, compiling to a web worker.

Curiously, the same code compiled within an Angular project does not manifest this problem. That's why I'm saying that it happens in at least some webpack configurations.

I'm of course open to any suggestions, I'd love to get rid of the exports-loader here.

from parse-latin.

That's great news.

I'd still play it safe, considering the plethora of possible configurations and versions (and things that can go wrong) in the wild, and import toString as a named import in the respective plugins.

Again, many thanks for your work on these libs!

from parse-latin.

It’s impossible to use version 3 of nlcst-to-string with a default import!

from parse-latin.

That's interesting.

I see it imported differently in retext-spell (as a named import), than in parse-latin (default import).

Is this a case of these libs using different versions of nlcst-to-string?

The error mention in the OP is caused by attempting a default import where there is no default export.

I might be missing something (maybe a lot), so apologies if I'm way off track here.

from parse-latin.

Different version!

The error is not the default export in the old version, Node.js and modern bundlers support using a default export for CJS module.exports. Some bundlers don’t though.

In the latest versions, all packages switched to named exports. Hence, to upgrade, they have to be used as named exports.

from parse-latin.

Different version!

That makes sense. In the case above, although the TS config module is set to CommonJS and all other modules work, I get the error above.

In the latest versions, all packages switched to named exports. Hence, to upgrade, they have to be used as named exports.

I just looked into the project dependencies for each, and retext-spell use nlcst-to-string version 3, while parse-latin uses version 2.

I see how that can confuse a bundler, since parse-latin and retext-spell get bundled together, yet they each use a different way of importing from different versions of the same lib, plus retext-spell ultimately depends on parse-latin, as far as I can tell.

I suppose updating parse-latin to use nlcst-to-string version 3 would solve this issue, would it?

from parse-latin.

Closing as I think this was an external issue!

from parse-latin.