xregexp: Import does not work anymore since version 4.4.0
We use xregexp in a shared library that is used in our client (Angular 10) as well as on our server (NodeJS / Webpack 5). Until version 4.3.0 we were able to import xregexp like this and everything worked as expected:
const XRegExp = require('xregexp');
Now we wanted to upgrade to version 4.4.0, but get the following error in the client application (Angular 10):
TypeError: XRegExp.matchRecursive is not a function
The server still works as expected.
Changing the import statement to const XRegExp = require('xregexp').default; solves the problem in the client but leads to this error on the server: TypeError: Cannot read property 'matchRecursive' of undefined.
We also tried import * as XRegExp from 'xregexp'; but this does not work either. Any ideas why this suddenly does not work anymore?
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 2
- Comments: 20 (8 by maintainers)
Commits related to this issue
- Add browser field to package.json to fix webpack This should close https://github.com/slevithan/xregexp/issues/305, see https://github.com/slevithan/xregexp/issues/305#issuecomment-740353997: > Actu... — committed to josephfrazier/xregexp by josephfrazier 4 years ago
- Add browser field to package.json to fix webpack This should close https://github.com/slevithan/xregexp/issues/305, see https://github.com/slevithan/xregexp/issues/305#issuecomment-740353997: > Actu... — committed to slevithan/xregexp by josephfrazier 4 years ago
Alright, I just published v4.4.1 with the fix from https://github.com/slevithan/xregexp/pull/308, can y’all confirm it works for you?
Actually, after reading https://webpack.js.org/configuration/resolve/#resolvemainfields more closely, it sounds like adding a
browserfield topackage.json, that points tolib/index.js(same asmain) should fix things.I’ll open a PR for that.
Hey all, maintainer who merged https://github.com/slevithan/xregexp/pull/281 here. I’m still wrapping my head around this issue, but I tend to agree with the following comments in that this is a webpack bug and/or configuration issue:
https://github.com/slevithan/xregexp/issues/305#issuecomment-729712632
https://github.com/slevithan/xregexp/issues/305#issuecomment-729763947
Here’s why: I installed Node 14 (to get module support), and ran both
importandrequireversions of the code, getting the same result from each (see theDetailsblock below). If webpack is supposed to make it so that you can use the module in the browser, the same way that you can from the server, then it doesn’t seem to be working properly here, and needs to be configured differently, as @jsg2021 suggested in their comments above.Let me know if I’ve overlooked anything. I do realize that even if webpack is technically wrong here, it might be easier to just work around it, rather than requiring XRegExp users to change their code, so I’m certainly still open to that.
For the OP, use:
If you’re using webpack and not using esm, you should probably configure webpack to ignore
modulemain fields since you are going against the grain.https://webpack.js.org/configuration/resolve/#resolvemainfields
This bug was introduced by the pull request https://github.com/slevithan/xregexp/pull/281 with this commit https://github.com/slevithan/xregexp/commit/99ee554835ac7a54bf2d73697601fe5520e97b06 by adding
"module": "./src/index.js"So lets see why this is causing issues.
Bundlers like webpack which support CommonJs and ESModules will start using ESModules from xregexp 4.4.0 instead of the previous CommonJs integration from 4.3.0.
After the change we get an object instead which includes the function as a default property:
@slevithan can we just revert #281 ?