jeffbski / wait-on

wait-on is a cross-platform command line utility and Node.js API which will wait for files, ports, sockets, and http(s) resources to become available

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

wait-on doesn't work due to lodash error

caiofbpa opened this issue · comments

Installation is successful:

$ npm install -g wait-on
npm WARN deprecated @hapi/formula@2.0.0: This version has been deprecated and is no longer supported or maintained
/usr/local/bin/wait-on -> /usr/local/lib/node_modules/wait-on/bin/wait-on
+ wait-on@5.0.1
added 15 packages from 18 contributors in 2.847s

But when trying to run:

$ wait-on -v http://web:8000
internal/modules/cjs/loader.js:796
    throw err;
    ^
Error: Cannot find module 'lodash/fp'
Require stack:
- /usr/local/lib/node_modules/wait-on/lib/wait-on.js
- /usr/local/lib/node_modules/wait-on/bin/wait-on
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:793:17)
    at Function.Module._load (internal/modules/cjs/loader.js:686:27)
    at Module.require (internal/modules/cjs/loader.js:848:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/usr/local/lib/node_modules/wait-on/lib/wait-on.js:11:72)
    at Module._compile (internal/modules/cjs/loader.js:955:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:991:10)
    at Module.load (internal/modules/cjs/loader.js:811:32)
    at Function.Module._load (internal/modules/cjs/loader.js:723:14)
    at Module.require (internal/modules/cjs/loader.js:848:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/usr/local/lib/node_modules/wait-on/lib/wait-on.js',
    '/usr/local/lib/node_modules/wait-on/bin/wait-on'
  ]
}

This started this morning, perhaps some dependency not pinned that got updated and broke it?

Same issue, but during the Travis build, inside docker env:

....
success Installed "wait-on@5.0.1" with binaries:
      - wait-on
...
internal/modules/cjs/loader.js:985
  throw err;
  ^

Error: Cannot find module 'lodash/fp'
Require stack:
- /usr/local/share/.config/yarn/global/node_modules/wait-on/lib/wait-on.js
- /usr/local/share/.config/yarn/global/node_modules/wait-on/bin/wait-on
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:982:15)
    at Function.Module._load (internal/modules/cjs/loader.js:864:27)
    at Module.require (internal/modules/cjs/loader.js:1044:19)
    at require (internal/modules/cjs/helpers.js:77:18)
    at Object.<anonymous> (/usr/local/share/.config/yarn/global/node_modules/wait-on/lib/wait-on.js:11:72)
    at Module._compile (internal/modules/cjs/loader.js:1158:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1178:10)
    at Module.load (internal/modules/cjs/loader.js:1002:32)
    at Function.Module._load (internal/modules/cjs/loader.js:901:14)
    at Module.require (internal/modules/cjs/loader.js:1044:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/usr/local/share/.config/yarn/global/node_modules/wait-on/lib/wait-on.js',
    '/usr/local/share/.config/yarn/global/node_modules/wait-on/bin/wait-on'
  ]
}

Confirmed: I have this problem, too, and pinning lodash to v4.17.15 prevents the problem.

I think this issue should be closed, and a new one opened on lodash, which seems to have removed fp/index.js in v4.17.17.

commented

Pinning to 4.17.15 also pins you to a version still vulnerable to this vulnerability. wait-on isn't directly affected by this vulnerability, since it doesn't use the vulnerable method in question, but this pinning would mean that wait-on would get flagged in security audit scans. I'm going to suggest that it may be time to just stop using lodash entirely.

Abandoning lodash feels like a big solution to a small problem. But if that's what makes sense to you, go ahead!

commented

Well, this is coming from a combination of factors... the security vulnerability I mentioned was ignored for months, including two months where a PR was open to fix the issue but the maintainer actively ignored it. And it's hard to say whether the current issue (lodash/fp not loading) will be take a similar amount of time to be addressed. I think if the maintainer of lodash is no longer willing to maintain it, it's reasonable to think about trying to shed that dependency.

Also, wait-on's usage of lodash isn't particularly intensive, and it has decent unit tests, so it might be a fairly painless piece of refactoring.

I will look into opening a PR to this effect. It might be today or tomorrow, can't say for sure right now.

I have a branch with a fix and am testing in travis now.

commented

Ah, in that case I will defer to @jeffbski! Thank you for your prompt work in any case.

Yes, agreed if lodash continues to be a source of problems for us then we will cut ties. For now I have updated to lodash@4.17.17 and just used the original lodash functions rather than the fp and have put in adapters for the few that need to be changed for the fp calling conventions.

They suggest 4.17.18, @jeffbski

Awesome thanks @rodush. I'm glad they resolved this quickly. I'll give it a try.

lodash@4.17.18 appears to work fine (fp is back). I have published wait-on@5.0.2 which uses the updated version. https://github.com/jeffbski/wait-on/releases/tag/v5.0.2

Thanks everyone who helped us to resolve this!

lodash@4.17.19 was also just dropped, so I published https://github.com/jeffbski/wait-on/releases/tag/v5.0.3 for good measure.