Using this in create-react-app results in build error

[wvbe]

For some site I'm using xml-renderer as a client-side transformation from XML to React component. It depends on fontoxpath ^3.9.2. When reinstalling this module recently the newest version of fontoxpath, 3.12.0, was installed which in turn depends on xspattern and whynot beyond that.

This crashed the build system of create-react-app with the following error:

/Users/wybe/Git/xml-renderer/node_modules/xspattern/dist/xspattern.mjs
Can't import the named export 'compileVM' from non EcmaScript module (only default export is available)

This references the very start of that built file;

import{compileVM as A}from"whynot";function…

Changing that portion to only use the default export fixed the error and allowed CRA's webpack to continue:

import whynot from "whynot";const A = whynot.compileVM;function…

To reproduce:

• Instantiate a new React project using npx create-react-app test
• cd test && npm install fontoxpath
• Import fontoxpath somewhere, which depends on xspattern

create-react-app version: 3.4.1
xml-renderer version: 3.0.2
fontoxpath version: 3.12.0
xspattern version: 1.2.1
whynot version: 3.0.3

[DrRataplan]

Create React App does not properly support the .mjs extension. I circumvented this issue in the fontoxpath playground by using customize-cra to patch in support for .mjs files. Op do 2 jul. 2020 om 22:02 schreef Wybe <notifications@github.com>:

…

For some site I'm using xml-renderer as a client-side transformation from XML to React component. It depends on fontoxpath ^3.9.2. When reinstalling this module recently the newest version of fontoxpath, 3.12.0, was installed which in turn depends on xspattern and whynot beyond that. This crashed the build system of create-react-app with the following error: /Users/wybe/Git/xml-renderer/node_modules/xspattern/dist/xspattern.mjs Can't import the named export 'compileVM' from non EcmaScript module (only default export is available) This references the very start of that built file; import{compileVM as A}from"whynot";function… Changing that portion to only use the default export fixed the error: import whynot from "whynot";const A = whynot.compileVM;function… To reproduce: - Instantiate a new React project using npx create-react-app test - cd test && npm install fontoxpath - Import fontoxpath somewhere, which depends on xspattern create-react-app version: 3.4.1 xml-renderer version: 3.0.2 fontoxpath version: 3.12.0 xspattern version: 1.2.1 whynot version: 3.0.3 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#18>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGKEJHTXZRXEWC4CXXUDMLRZTRUXANCNFSM4OPGMS5Q> .

[wvbe]

For anyone else running into this problem, I've succesfully circumvented this issue in several projects usingcreate-react-app, or storybook, or Gatsby, by forcing an older version of fontoxpath (3.9.1 does not yet depend on xspattern) to be used. Sometimes npm-force-resolutions helps but it is not always useful/possible, so I've also kept the dependency of xml-renderer on fontoxpath at an older version.

AKA not using xspattern at all fixed the problem.

[bwrrp]

Hi Wybe,

While I would love for this library to work everywhere with minimal configuration, it seems the story around bundling ESM is currently far from being stabilized. I view renaming the bundle files as a major change, so I'd like to avoid messing around too much to get to a state that works everywhere, let alone have that break again when node, typescript or some bundler change their mind once again. That said, if you have a link to some guide on a setup that works better than what I have currently, please do let me know.

For create-react-app in particular, most seem to be of the opinion that this is an issue with that tool, and work-arounds seem to exist (e.g., https://stackoverflow.com/questions/64002604/how-to-make-create-react-app-support-mjs-files-with-webpack). Perhaps that can be of use until the situation around ESM improves?

[DrRataplan]

I filed this issue to see what the CRA team thinks of this: facebook/create-react-app#10356

[wvbe]

Thanks @bwrrp @DrRataplan . I agree that the fault is probably with Webpack, not with you. However, that doesn't make a fix any easier for me. I'm currently happy with using an outdated version of fontoxpath and so on, although the topic did come up again in another discussion (with DrRataplan) about something else.

If I were to run into an urgent unavoidable reason to upgrade to a newer fontoxpath I will spend time on overriding the webpack config of whatever framework has implemented Webpack (I dont normally configure Webpack myself). The CRA resources you've posted will help, I'm sure some of it carries over to Gatsby etc. too 👍

Thanks!

[EvadeHaas]

I just ran into the same issue for a new app that we are creating. I would be great if we could find a better fix for this.

[bwrrp]

As the mjs extension seems to be the main issue here, I'll see if I can experiment a little with whether things work better in most bundlers if both of the bundles use .js instead.

[bwrrp]

Results of experimenting, with no or minimal config added for each of these:

Bundler / environment	Uses	Works with .mjs?	Works with .js?
Parcel	ESM	✔	✔
Snowpack	ESM	✔	✔
Rollup (with node-resolve plugin)	ESM	✔	✔
CRA	ESM	❌1.	✔2.
Gatsby (xspattern linked)	ESM	✔	❌3.
Gatsby (xspattern installed)	ESM	❌1.	✔
Node.js	UMD4.	N/A	✔

1. Failed with error mentioned above
2. Interestingly, CRA also works when using .js for the xspattern EMS bundle, but keeping the .mjs extension for its whynot dependency. It appears that the problem in CRA only occurs when a .mjs bundle tries to import something else...
3. npm linking xspattern into the gatsby app apparently triggered a bug in its webpack configuration where it appeared to apply its linting rules to xspattern's ESM bundle. npm installing the package instead did not trigger this problem. Weirdly, a linked xspattern did seem to avoid the error in this issue, while the installed xspattern triggered the same error as with CRA...
4. Node.js seems to ignore the package.json "module" field and instead looks at the "type" and "main" fields. The upcoming "exports" property may help here, but UMD works for now until that is more widely supported.

Given these results, and despite the weird behavior with linking xspattern in the gatsby app, I'm inclined to try switching all of my libs to the .js extension for now. Installing these libs as a dependency in a CRA or Gatsby app is probably more likely than npm linking it. Node continuing to use the UMD bundle doesn't seem like a problem at this time.

[bwrrp]

Judging by FontoXML/fontoxpath#286 this has now been resolved, so I'm closing this issue.