Import does not work anymore since version 4.4.0

[gizmodus]

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?

[sachithd]

Facing the same issue.

[slevithan]

This could be a side effect of having upgraded most of the dependencies in v4.4.0, or it could have stemmed from adding TypeScript definitions in the same release. Any pull requests that fix this are most welcome.

[josephfrazier]

I suspect this may be an Angular issue, see #294

[jantimon]

This bug was introduced by the pull request #281 with this commit 99ee554 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.

require('xregexp') // --> function (commonJs)

After the change we get an object instead which includes the function as a default property:

require('xregexp') // -> { esModule: true, default: function } (esModules)

@slevithan can we just revert #281 ?

[jsg2021]

If you're using webpack and not using esm, you should probably configure webpack to ignore module main fields since you are going against the grain.

https://webpack.js.org/configuration/resolve/#resolvemainfields

[jsg2021]

For the OP, use:

import XRegExp from 'xregexp';

[jantimon]

@jsg2021 we are using a lot of es6 node_modules for better tree shaking so disabling the module field isn't an option for us

right now we are using the @adobe/htlengine which is using xregexp somewhere in its xss validaiton logic: https://github.com/adobe/htlengine/blob/ffcfeecc1d60e0f8f47c15be68ce794a8620b6d6/src/runtime/xss_api.js#L17

your change broke our entire pipeline :)

if you say all xregexp webpack users need to change their webpack config and or switch from require to import might be a possible way however that's a breaking change

[jsg2021]

My PR is more than 9mo old and I think XRegExp was still on 3.x...

To your point, the evidence says this change is worthy of a major version bump.

[jantimon]

4.4.0 was released 20 days ago and this issue was filed 14 days ago

xregexp 4.3.0 has no module field:
https://unpkg.com/xregexp@4.3.0/package.json

xregexp 4.4.0 has a module field:
https://unpkg.com/xregexp@4.4.0/package.json

I don't know why it got into the 4.4.0 release..

So there are two options:

1. we find a way to fix the issue for 4.5.0
2. we revert the change for 4.5.0 and release the changes from 4.4.0 as 5.0.0

However option 2 would mean that xregexp can't be used anymore in any isomorphic environment

[jsg2021]

However option 2 would mean that xregexp can't be used anymore in any isomorphic environment

Why would it mean that? front-end and back-end code could use it just the same. Just older commonjs code would have to adapt.

[jantimon]

For node 12 there is only commonJs - that's why the @adobe/htlengine and other isomorphic packages use commonJs

However if require('xregexp') works differently for browser and node environments this approach will not work anymore

[jsg2021]

For node 12 there is only commonJs - that's why the @adobe/htlengine and other isomorphic packages use commonJs

However if require('xregexp') works differently for browser and node environments this approach will not work anymore

That's fair, but 14 is the current LTS, so that would just be a small window of awkward transition.

Another option to try in the meantime, is to add xregexp to the externals so that webpack doesn't bundle it and lets node process the require().

[slevithan]

I think I'm okay with requiring node 14 in an XRegExp 5 (any issues can perhaps be noted in the "Installation and usage" section of README.md), but I'm not actively supporting XRegExp these days and I'm not very familiar with the details of cjs/umd/esm, rollup, babel, webpack, etc. so these kinds of changes are harder for me to test.

I'd be happy to merge and release pull requests with all changes needed for an XRegExp v4.5.0 revert and v5.0.0 reintroduction of this change (possibly adding @jsg2021's #282 for v5). If anyone wants to take that on, I'd really appreciate it, and would additionally appreciate the descriptions being clear and including release notes (like https://github.com/slevithan/xregexp/releases) that I can attach when publishing. (No need to do version bumping like c3342b5 unless you want to since I can handle that.)

[jantimon]

Cool thanks @slevithan 👍

for 4.5 all we need to do is to delete the module entry in package.json.. I can prepare a pr for this

for 5.0 I have an idea how we can make use of the changes @jsg2021 did also for node 12:

commonJs

   module.exports = { default: XRegExp }

es modules (just like before)

  export default XRegExp

that way the typings would work correctly and it would be isomorphic as both ways would work e.g.:

import XRegExp from 'XRegExp';
require('XRegExp').default

another possible solution which might be even cleaner would be

commonJs

   module.exports = { XRegExp }

es modules

  export const XRegExp

the imports would look like:

import {XRegExp} from 'XRegExp';
require('XRegExp').XRegExp