dependencies in package.json with "^"

[pszabo1]

hello.

we've just seen that your package json, also in released versions, does include the following dependencies: "dependencies": { "bluebird": "^3.4.1", "lodash": "^4.13.0", "mkdirp": "^0.5.1", "mongodb": "^2.2.1", "nomnom": "^1.6.2" }

the usage of "^" leads to the fact that installing the "released" mongodb-migrations module installs potential changed submodules. In our case, the used implementation of mongodb (2.2.19) seems to be incompatible with mongodb-migrations 0.5.2.

is that a desirable behaviour? there are possibilities like npm shrinkwrap or just using static versions which would prevent such problems.

[emirotin]

Semver is specifically designed to not use the static versions. Using carets is the common practice advised by npm and it's the default behavior with npm install. You would see this in almost any npm package.

Of course it assumes that the library authors do follow the semver principles. In particular that means that patch changes (like from mongo 2.2.1 to 2.2.19) should never change the API, and minor changes (from 2.0.0 which is the dependency of 0.5.2 to the modern 2.2) should only add the new APIs in backward-compatible way.

I've just ran the tests with the mongodb module 2.2.16 and 2.2.19, passed in both cases with the current master which is 0.8.3. I've also checked 0.5.2 with mongodb 2.2.19 and it passes the tests suite too.

But 0.5.2 is an old version and it can obviously have bugs fixed in the later versions. I don't have resources to provide support for older 0.x versions, so upgrading to the newest version is strongly advised.

Shrinkwrapping is a good idea regardless though, will implement it later together with yarn.lock.

[pszabo1]

Thanks for information. I totally agree with you about that. I was just not sure if this is a desired handling. I've had too many problems with using caret for everything that is "productive" for me, because of exactly such issues with external packages.

I'll check if upgrading mongodb-migration itself is fixing the problems.

Br

[emirotin]

Closing it unless more specific issue is reported.

[pszabo1]

I've reproduced the problem in an indenpendet environment:

windows 10 prof. npm --version: 3.10.6 node --version: v5.7.0 package.json: { "name": "test-mongodb-migrations", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo "Error: no test specified" && exit 1" }, "author": "", "license": "ISC", "dependencies": { "mongodb-migrations": "^0.8.4", "mongoose": "4.0.8" } }

index.js: var mm = require('mongodb-migrations'); var mongoose = require("mongoose");

function execute() { var migrator = new mm.Migrator({ host: 'localhost', port: '27017', db: 'db, collection: '_migrations', poolSize: 5 }); } execute();

this seems to be a incompatibility between the mongodb versions used by [email protected] and most current version of mongodb-migrations.

This is just an information for others, I'll fix this on my side.

[emirotin]

Interesting, thanks for reporting!

I'll try to repro and see what specifically is an issue.

[emirotin]

Because in case of incompatible versions npm should just install the 2 copies of the package and no conflict should occur.

[pszabo1]

This is what i would expect either.

[amongouser]

@emirotin yarn and the new npm@5 solve this using lock files.

I'd close this issue.