parse-latin

parse-latin copied to clipboard

At least in some webpack configurations, because some of the parse-latin plugins import toString from nlcst-to-string as default, while toString is not in fact a default export, webpack fails with errors like:

ERROR in ./node_modules/parse-latin/lib/plugin/break-implicit-sentences.js 33:61-69
export 'default' (imported as 'toString') was not found in 'nlcst-to-string' (possible exports: toString)

The solution is to either mark toString as a default export in the nlcst-to-string repo, or correct the default import to a named import in the parse-latin plugin files that import toString.

Please let me know if you can address it, or want me to do a pull request with one of the two fixes above.

Thanks for your great work on this suite!

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?

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.

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!

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!

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

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.

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.

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?

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.

Closing as I think this was an external issue!