Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot find module 'xregexp' #11

Closed
stefan-leye opened this issue Aug 23, 2017 · 13 comments
Closed

Cannot find module 'xregexp' #11

stefan-leye opened this issue Aug 23, 2017 · 13 comments

Comments

@stefan-leye
Copy link

stefan-leye commented Aug 23, 2017

Since yesterday I get the error message: "Cannot find module 'xregexp'", when using the parser generator.
A bit of investigation showed that the xregexp dependency points to the master of a forked xregexp lib, that has been changed in the last hours.

I think we have two issues here:

  1. The reported problem with xregexp.
  2. In general it is bad practice to point to a dependency master. In our project, we point at a specific version (0.4.18-180) of jison-gho, to make sure that things don't break overnight. However, this happened yesterday, as your sub dependencies changed.
@nwhetsell
Copy link

I’m running into this as well.

@GerHobbelt
Copy link
Owner

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.

GerHobbelt added a commit to GerHobbelt/xregexp that referenced this issue Aug 27, 2017
GerHobbelt added a commit to GerHobbelt/json5 that referenced this issue Aug 27, 2017
GerHobbelt added a commit to GerHobbelt/ast-types that referenced this issue Aug 27, 2017
@nwhetsell
Copy link

nwhetsell commented Aug 27, 2017

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 added a commit to GerHobbelt/recast that referenced this issue Aug 27, 2017
…ype and OpaqueType.

- bumped build revision and moving towards public 'scoped package' releases as per https://docs.npmjs.com/misc/scope; this is also related to GerHobbelt/jison#11
GerHobbelt added a commit to GerHobbelt/lex-parser that referenced this issue Aug 27, 2017
GerHobbelt added a commit to GerHobbelt/lex-parser that referenced this issue Aug 27, 2017
GerHobbelt added a commit to GerHobbelt/lex-parser that referenced this issue Aug 27, 2017
GerHobbelt added a commit to GerHobbelt/ast-util that referenced this issue Aug 27, 2017
…ases as per https://docs.npmjs.com/misc/scope; this is also related to GerHobbelt/jison#11 -- rant: this need to change every bloody `require()` call in the code for a 'scoped package' is what I particularly dislike about this approach, but so far, it's the best we've got as long as the entire world hasn't upgraded to packge-lock.json support...  /rant
GerHobbelt added a commit to GerHobbelt/jison-lex that referenced this issue Aug 27, 2017
…pmjs.com/misc/scope; this is also related to GerHobbelt/jison#11 -- rant: this need to change every bloody `require()` call in the code for a 'scoped package' is what I particularly dislike about this approach, but so far, it's the best we've got as long as the entire world hasn't upgraded to packge-lock.json support...  /rant
GerHobbelt added a commit to GerHobbelt/json2jison that referenced this issue Aug 27, 2017
…ases as per https://docs.npmjs.com/misc/scope; this is also related to GerHobbelt/jison#11 -- rant: this need to change every bloody `require()` call in the code for a 'scoped package' is what I particularly dislike about this approach, but so far, it's the best we've got as long as the entire world hasn't upgraded to packge-lock.json support...  /rant
GerHobbelt added a commit to GerHobbelt/ebnf-parser that referenced this issue Aug 27, 2017
…pmjs.com/misc/scope; this is also related to GerHobbelt/jison#11 -- rant: this need to change every bloody `require()` call in the code for a 'scoped package' is what I particularly dislike about this approach, but so far, it's the best we've got as long as the entire world hasn't upgraded to packge-lock.json support...  /rant
GerHobbelt added a commit to GerHobbelt/ebnf-parser that referenced this issue Aug 27, 2017
… as per https://docs.npmjs.com/misc/scope; this is also related to GerHobbelt/jison#11 -- rant: this need to change every bloody `require()` call in the code for a 'scoped package' is what I particularly dislike about this approach, but so far, it's the best we've got as long as the entire world hasn't upgraded to packge-lock.json support...  /rant
GerHobbelt added a commit to GerHobbelt/jison-lex that referenced this issue Aug 27, 2017
…ndencies listed in package.json. This is also related to GerHobbelt/jison#11.
GerHobbelt added a commit to GerHobbelt/jison2json that referenced this issue Aug 27, 2017
…ases as per https://docs.npmjs.com/misc/scope; this is also related to GerHobbelt/jison#11 -- rant: this need to change every bloody `require()` call in the code for a 'scoped package' is what I particularly dislike about this approach, but so far, it's the best we've got as long as the entire world hasn't upgraded to packge-lock.json support...  /rant
GerHobbelt added a commit to GerHobbelt/jison2json that referenced this issue Aug 27, 2017
…ndencies listed in package.json. This is also related to GerHobbelt/jison#11.
GerHobbelt added a commit that referenced this issue Aug 27, 2017
… they get copied into lib/util/

- patched all `require()` statements in the examples as well to match the 'scoped package' dependencies listed in package.json. This is also related to #11. Grmbkl!@#$%^&*!
- jison modules DO NOT belong in the **dependencies**, but should reside in the **devDependencies**. Where I screwed this up, I don't know (git blame should hand me the answer to that but I'll do that later when I feel like it), but now that we move towards 'scoped packages' it's biting me in the aXX!  :-(
- regenerated library files
@GerHobbelt
Copy link
Owner

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
Copy link
Owner

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 added a commit to GerHobbelt/jison-lex that referenced this issue Aug 27, 2017
@GerHobbelt
Copy link
Owner

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
Copy link
Owner

@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
Copy link
Owner

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
Copy link
Owner

@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
Copy link
Author

@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
Copy link
Owner

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
Copy link
Author

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

@GerHobbelt
Copy link
Owner

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants