Cannot find module 'xregexp' about jison

[nwhetsell]

I’m running into this as well.

[GerHobbelt]

xregexp should behave as expected again.

I'm looking into moving to 'scoped npm modules' so that I can get rid of the github#master references and still have a fast turn-around while developing.

[nwhetsell]

I just ran

npm install https://github.com/GerHobbelt/jison/archive/0.4.18-186.tar.gz
node_modules/jison-gho/lib/cli.js node_modules/jison-gho/examples/ansic.jison

on macOS 10.12.6 and still get

module.js:491
    throw err;
    ^

Error: Cannot find module 'xregexp'
    at Function.Module._resolveFilename (module.js:489:15)
    at Function.Module._load (module.js:439:25)
    at Module.require (module.js:517:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/…/node_modules/jison-gho/lib/util/regexp-lexer.js:7:15)
    at Module._compile (module.js:573:30)
    at Object.Module._extensions..js (module.js:584:10)
    at Module.load (module.js:507:32)
    at tryModuleLoad (module.js:470:12)
    at Function.Module._load (module.js:462:3)

[GerHobbelt]

WARNING: work is underway to solve this, but be reminded that build 0.6.0-187 still hasn't been round-trip tested, so expect another release after that one before this can be said to be 'solved'.

[GerHobbelt]

For those curious folks: 'round trip testing' means running this sequence with zero failures:

make superclean
make prep
make

which will clean the NPM node_modules/ stores, re-install the npm packages and then run all the builds and tests.

[GerHobbelt]

Okay, I think I've got it nailed now.
Sorry for the trouble y'all had. Release 0.6.0-188 should not exhibit this problem anymore.

Notes on that release:
a few things have changed, though nothing major unless:

• you're an avid user of %parse-params in your grammar files: from 0.6.0-xxx forward all %parse-params end up in the yy shared context object, saving us quite a bit of parameter passing call overhead in both parser and lexer, or
• you expect the parseError() API this reference to point at the yy context: that is not true any more: this will reference the current parser or lexer instance (to be precise: the instance that invoked this particular parseError()); yy is available inside parseError() via the hash parameter already.

[GerHobbelt]

@stefan-leye :
I saw you forked the repo; can you help me and confirm / deny that this issue is fixed in this release?
Do you observe other behaviour which might bother you? (e.g. #12)

Thanks!

[GerHobbelt]

fixed in latest release 0.6.0-191; jison dependencies now use scoped packages where necessary (https://docs.npmjs.com/misc/scope) plus npm's package-lock.json should really fix this issue as it stores the unique hash for every dependency as it has been installed on the machine which produces the release(s).

[GerHobbelt]

@stefan-leye: ping? Can we confirm this fixed with -191 or later?

(FYI: I've switched to using scoped packages for the submodules so this type of problem should be gone or at least severely mitigated in the future.)

[stefan-leye]

@GerHobbelt ah sorry, for not replying. I switched to an older version of jison, that works for our project.
To avoid breaking thinks we update our dependencies on the start of a development cycle, only. So I cannot check the problem until the next development cycle starts (propably in November). Feel free to close the ticket, if you don't want to wait..

[GerHobbelt]

Thanks for the info, I'll keep it open then until you get an opportunity to verify.

(Off-topic: I hope to have some more work done on jison by November -- fingers crossed 😉 -- so it would be great to hear about your experience then. (the main issue now is documentation; others using this helps as a strong motivator to give that one a fresh shove in the gluteus maximus)

[stefan-leye]

@GerHobbelt finally tried it out. Everthing works fine :)

[GerHobbelt]

Superb! 👍

I'm going to close this issue; if anything pops up, please create a new one and reference this one (or re-open this issue).

Enjoy!