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

dependencies in package.json with "^" #37

Open
pszabo1 opened this issue Jan 9, 2017 · 8 comments
Open

dependencies in package.json with "^" #37

pszabo1 opened this issue Jan 9, 2017 · 8 comments

Comments

@pszabo1
Copy link

pszabo1 commented Jan 9, 2017

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

emirotin commented Jan 9, 2017

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

pszabo1 commented Jan 9, 2017

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

Closing it unless more specific issue is reported.

@pszabo1
Copy link
Author

pszabo1 commented Jan 16, 2017

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 mongoose@4.0.8 and most current version of mongodb-migrations.

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

@emirotin
Copy link
Owner

Interesting, thanks for reporting!

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

@emirotin emirotin reopened this Jan 16, 2017
@emirotin
Copy link
Owner

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

@pszabo1
Copy link
Author

pszabo1 commented Jan 16, 2017

This is what i would expect either.

@amongouser
Copy link

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

I'd close this issue.

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

No branches or pull requests

3 participants