-
Notifications
You must be signed in to change notification settings - Fork 813
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
Pin our own dependencies #2065
Comments
Do you refer to dependencies between packages within one repo (e.g. For packages within on repo it sounds reasonable as they are anyway released in one shot. Usually it's a good thing to get patch updates like security fixes,.. automatically. |
Within repo. API should still be at least |
isn't there still a risk to get this mixed up if people use something from contrib where core components are referenced by |
You are right, unfortunately Most users I suppose are installing dependencies with caret If you have an idea how to maintain pinning dependencies from contib packages as well, that would make me super happy :) |
The only way to make contrib also pinnable would be to remove ranges altogether and release a new contrib each time core is released. |
I think in a real app it should be not that bad. As far as I know npm installs only a second instance if the version ranges don't allow de duplication. |
Yes that is correct |
Thanks for the help. I created a demo app with these dependencies:
and in my node_modules root directory there is installation of I am working with Anyway, I think this case is less important then the amount of time we put into it. I was just trying to make my installations more stable and predictable, by getting as little code as possible "automatically installed" via semver ranges. |
I have another example where current version dependency breaks. Consider this code: import { NodeTracerProvider } from '@opentelemetry/node';
import { SimpleSpanProcessor, ConsoleSpanExporter } from '@opentelemetry/tracing';
const provider = new NodeTracerProvider();
// SimpleSpanProcessor is imported from 0.18.0
// addSpanProcessor is imported from @opentelemetry/node@0.18.0, which expect SpanProcessor with the interface from 0.18.2 due to it's caret dependency
provider.addSpanProcessor(new SimpleSpanProcessor(new ConsoleSpanExporter())); {
"name": "otel-versions",
"version": "1.0.0",
"main": "index.js",
"license": "MIT",
"scripts": {
"start": "ts-node-dev app.ts"
},
"devDependencies": {
"ts-node-dev": "^1.1.6",
"typescript": "^4.2.3"
},
"dependencies": {
"@opentelemetry/node": "0.18.0",
"@opentelemetry/tracing": "0.18.0"
}
} To my understanding, this is a perfectly valid setup of opentelemetry, but when compiled, it generates the following error:
This happens because To my understanding, for the project to currently work, it requires that end users install core packages with caret (^0.18.0). I would prefer of course to support installation of pinned versions ( |
Can you try with NPM?
The interface actually didn't change, but a new private property was apparently added. |
So would I. I think the only way to do this is for us to pin our own dependencies. I looked at angular and it appears they do the same thing in order to support pinning. |
Tried with NPM and it works. So this approach will work well for npm users but not for yarn users |
Wonder if yarn has any flags to force the npm behavior. Could this be considered a yarn bug? |
Cool, thanks for looking into it. My point is that patch versions should not break application/compilation, but it's really easy for breaking behavior to sneak in by mistake.
Should we open an issue for that? |
I vote for pinning them. Actually, I can't think of a drawback to pining own dependencies. Users which install core packages with caret, already have the latest version of the direct dependency, and it will install the latest version of pinned sub dependency as well |
Tested it again with yarn, and I see the same behavior as npm. Not sure how to reproduce the original setup in which I observed the problem, but maybe it was just an issue on my machine. |
Seems it's by far easier to introduce a breaking change via typescipt compared to javascript. Is anyone aware of a guideline what needs to be done to avoid such issues? |
This is only "breaking" so far as if you have multiple versions of In general, the way to avoid this is to use interfaces everywhere possible instead of using concrete classes as the type for function arguments and returns. |
In this particular case, the |
Created #2075 for this |
Currently it is not possible for users to pin versions without a package-lock because we depend on "carat" versions of our own packages. If we release a new patch version, end users will get the new versions even if they are trying to pin dependency versions which doesn't give them a chance to test new versions.
/cc @blumamir
The text was updated successfully, but these errors were encountered: