relative-deps icon indicating copy to clipboard operation
relative-deps copied to clipboard

Update dependency version

Open mtiller opened this issue 6 years ago • 4 comments

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?

mtiller avatar Oct 31 '19 20:10 mtiller

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 .

mweststrate avatar Oct 31 '19 20:10 mweststrate

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.

mtiller avatar Nov 01 '19 15:11 mtiller

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 .

mweststrate avatar Nov 02 '19 08:11 mweststrate

Yes, we can detect package.json dependencies changes.

zhangwilling avatar May 08 '20 09:05 zhangwilling