3.2.0 and 3.2.1 packages include a nested node_modules/ directory with commons

[rtyler]

It seems that both the 3.2.0 and 3.2.1 packages for feathersjs/feathers include a node_modules directory

Steps to reproduce

• Install either 3.2.0 or 3.2.1 of @feathersjs/feathers

Expected behavior

• Expected just the lib/directory and some other bits to be in the package

Actual behavior

 tyler   master  …  node_modules  @feathersjs  feathers  pwd
/home/tyler/source/github/jenkins-infra/evergreen/distribution/client/node_modules/@feathersjs/feathers
 tyler   master  …  node_modules  @feathersjs  feathers  tree node_modules
node_modules
└── @feathersjs
    └── commons
        ├── CHANGELOG.md
        ├── lib
        │   ├── commons.js
        │   ├── filter-query.js
        │   ├── hooks.js
        │   ├── test
        │   │   ├── client.js
        │   │   └── fixture.js
        │   └── utils.js
        ├── LICENSE
        ├── package.json
        └── README.md

4 directories, 10 files

This seems to be the root cause of a wacky issue when I end up running my application which imports @feathersjs/feathers

info: Checking registration status..
debug: Writing public key to /evergreen/keys/evergreen.pub
debug: Writing private key to /evergreen/keys/evergreen-private-key
info: Creating registration..
error: Failed to register: message=Cannot read property 'eventMappings' of undefined, stack=TypeError: Cannot read property 'eventMappings' of undefined
    at Object.<anonymous> (/evergreen/client/node_modules/@feathersjs/feathers/lib/events.js:9:27)
    at promise.then.hookObject (/evergreen/client/node_modules/@feathersjs/feathers/node_modules/@feathersjs/commons/lib/hooks.js:142:73)
    at process._tickCallback (internal/process/next_tick.js:68:7)
    at Function.Module.runMain (internal/modules/cjs/loader.js:745:11)
    at startup (internal/bootstrap/node.js:266:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:596:3), pubKey=04abe001df28c407485b2933027ab2f5145d08539f35d7dcec7510ea0608d51e82a266b7d8439f2d458bd68e96e35f1262ae5725da4bf563471974547f2ffe1381, curve=secp256k1, method=create, path=null, type=error, $ref=$["hook"]["0"], method=create, path=null, $ref=$["hook"]
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! evergreen-client@1.0.0 client: `node src/client.js`
npm ERR! Exit status 1

System configuration

Tell us about the applicable parts of your setup.

Module versions (especially the part that's not working):

NodeJS version: 10

Operating System: Linux

Browser Version:

React Native Version:

Module Loader:

[daffl]

At the moment it might not be unusual to have different versions of @feathersjs/commons. I'd try removing node_modules and package-lock.json and then reinstalling. npm ls @featherjs/commons will show you who is depending on what. The latest versions of all @feathersjs/* modules (and the @feathersjs/client client side build) should work together as expected but I can not guarantee that for other third party plugins.

[rtyler]

Perhaps I'm misunderstanding what's happening under the covers here.

So the package itself doesn't include node_modules (just verified that), but this is npm's clever way of managing two modules in the tree wanting to have different versions of the same dependency?

Considering the following dependency tree, perhaps this stack trace is more of a bug for the interaction between the 3.2.1 feathers module and 3.0.0 of `commons?

evergreen-client@1.0.0 /home/tyler/source/github/jenkins-infra/evergreen/distribution/client
├─┬ @feathersjs/express@1.2.3
│ └── @feathersjs/commons@1.4.1
├─┬ @feathersjs/feathers@3.2.1
│ └── @feathersjs/commons@3.0.0
├─┬ @feathersjs/rest-client@1.4.1
│ └── @feathersjs/commons@1.4.1  deduped
└─┬ @feathersjs/socketio@3.2.2
  └─┬ @feathersjs/transport-commons@4.1.1
    └── @feathersjs/commons@1.4.1  deduped

[daffl]

npm will create a node_modules sub-directory if the version is different than the shared version.

In your case this is because not all modules are on their latest version and depend on the same library. For example, @feathersjs/express should be at version 1.2.5 or later, @feathersjs/rest-client at 1.4.3 etc. This is why I recommended to remove your package-lock.json and reinstalling everything because it will automatically install the latest compatible version.

I also found tools like npm-check-updates pretty useful. With package-lock.json and node_modules removed it will automatically update all dependent versions in the package.json.

[rtyler]

Assuming that I would have been prevented from falling into this dependency trap with the feathers-cli upgrade command, feel free to close this out.

[daffl]

Not sure about that but I found that it always makes sense to clear out the package-lock.json when manually updating any dependencies. I don't think it should've thrown an error, on the other hand, the assumption was that npm always installs the latest compatible version (and updates the package-lock.json accordingly) but that does not always seem to be the case for some reason.

[daffl]

Closing since the solution at the moment is to make sure that the latest patch version of all @feathersjs/* packages is installed.

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue with a link to this issue for related bugs.