relative-deps
relative-deps copied to clipboard
Update dependency version
Perhaps I'm going about this the wrong way, but when I depend on a sibling package, I have it listed in both dependencies and relativeDependencies. Now relativeDependencies just has the relative path to the sibling package. But dependencies lists the actual version number of that package. But the problem is that this isn't kept in sync.
Let me try and explain with an example. Let's assume package package-a exists in one directory and another package, package-b, exists next to it. In package-b/package.json, we have:
"dependencies": {
...
"package-a": "^1.0.0"
},
"relativeDependencies": {
"package-a": "../package-a"
}
But let's assume that package-a/package.json contains:
{
"name": "package-a",
"version": "1.1.0",
...
}
When I run relative-deps in package-b, it correctly rebuilds it and installs it in node_modules/package-a, but it doesn't look at package-a/package.json and read the version number out and then replace it in package-b/package.json so that it reads:
"dependencies": {
"package-a": "^1.1.0"
}
...
This is a big problem for me because I might have many such libraries that depend on package-a that are all siblings (e.g.,, package-c, package-d) and they can end up all listing a different version of the dependency which can, in turn, cause problems later.
I'm curious...is there some way to get around this that makes such a feature here moot?
I think an --auto-update-dependency-version flag could be added, to automatically bump the version every time a relative dependency is installed? I think I wouldn't it by default, because in many dev setups version is just 0.0.0 and only determined during the release process for example. I feature like this tends to put the version always "one behind"? (after doing a publish of package a, you would still need to make sure relative deps is run for the others so that their versions get bumped)
On Thu, Oct 31, 2019 at 8:36 PM Michael Tiller [email protected] wrote:
Perhaps I'm going about this the wrong way, but when I depend on a sibling package, I have it listed in both dependencies and relativeDependencies. Now relativeDependencies just has the relative path to the sibling package. But dependencies lists the actual version number of that package. But the problem is that this isn't kept in sync.
Let me try and explain with an example. Let's assume package package-a exists in one directory and another package, package-b, exists next to it. In package-b/package.json, we have:
"dependencies": { ... "package-a": "^1.0.0" }, "relativeDependencies": { "package-a": "../package-a" }
But let's assume that package-a/package.json contains:
{ "name": "package-a", "version": "1.1.0", ... }
When I run relative-deps in package-b, it correctly rebuilds it and installs it in node_modules/package-a, but it doesn't look at package-a/package.json and read the version number out and then replace it in package-b/package.json so that it reads:
"dependencies": { "package-a": "^1.1.0" } ...
This is a big problem for me because I might have many such libraries that depend on package-a that are all siblings (e.g.,, package-c, package-d) and they can end up all listing a different version of the dependency which can, in turn, cause problems later.
I'm curious...is there some way to get around this that makes such a feature here moot?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mweststrate/relative-deps/issues/15?email_source=notifications&email_token=AAN4NBAH2OEBFYACJXKNJITQRM6TVA5CNFSM4JHSETJ2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HV5MKMQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAN4NBBOSBMGG5JY6XL7OADQRM6TVANCNFSM4JHSETJQ .
The "one behind" (or many behind) issue I see is with using oao (for example). It wants to bump all the versions itself at the time of publication. So if I want to update intra-monorepo dependencies, I have to know what version I'm going to release for each package (even though they haven't been actually updated in the package.json/version info prior to running oao publish. It is bit frustrating. I'm not sure relative-deps solves that problem, but it might very well allow me to avoid using oao altogether (not sure).
It seems like this would really need to be integrated into the publication process in some way. What I can currently do (with oao) is to do an oao reset-all-versions so all packages are updated to a given version, then I could run relative-deps --auto-update-dependency-version so that all dependencies were updated to use the latest versions set by reset-all-versions and then run oao publish --no-bump which would publish everything at their current version and not have it automatically ratchet up versions. But I still feel like I'm doing something wrong somewhere to have to do all this.
I think that is the problem lerna tries to solve? But yeah that is why I didn't care about versions so far. Locally linked package are always "correct", and coordinated releases are a second problem to solve
Op vr 1 nov. 2019 15:36 schreef Michael Tiller [email protected]:
The "one behind" (or many behind) issue I see is with using oao (for example). It wants to bump all the versions itself at the time of publication. So if I want to update intra-monorepo dependencies, I have to know what version I'm going to release for each package (even though they haven't been actually updated in the package.json/version info prior to running oao publish. It is bit frustrating. I'm not sure relative-deps solves that problem, but it might very well allow me to avoid using oao altogether (not sure).
It seems like this would really need to be integrated into the publication process in some way. What I can currently do (with oao) is to do an oao reset-all-versions so all packages are updated to a given version, then I could run relative-deps --auto-update-dependency-version so that all dependencies were updated to use the latest versions set by reset-all-versions and then run oao publish --no-bump which would publish everything at their current version and not have it automatically ratchet up versions. But I still feel like I'm doing something wrong somewhere to have to do all this.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mweststrate/relative-deps/issues/15?email_source=notifications&email_token=AAN4NBBBHR37DSCIW7ZX7ZLQRREGZA5CNFSM4JHSETJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC3IX2Y#issuecomment-548834283, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAN4NBA2VCYXTQPUAELWTUDQRREGZANCNFSM4JHSETJQ .
Yes, we can detect package.json dependencies changes.