Update dependency version #15
Comments
|
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 ***@***.***> 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
<#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 It seems like this would really need to be integrated into the publication process in some way. What I can currently do (with |
|
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
<#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. |
Perhaps I'm going about this the wrong way, but when I depend on a sibling package, I have it listed in both
dependenciesandrelativeDependencies. NowrelativeDependenciesjust has the relative path to the sibling package. Butdependencieslists 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-aexists in one directory and another package,package-b, exists next to it. Inpackage-b/package.json, we have:But let's assume that
package-a/package.jsoncontains:{ "name": "package-a", "version": "1.1.0", ... }When I run
relative-depsinpackage-b, it correctly rebuilds it and installs it innode_modules/package-a, but it doesn't look atpackage-a/package.jsonand read the version number out and then replace it inpackage-b/package.jsonso that it reads:This is a big problem for me because I might have many such libraries that depend on
package-athat 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?
The text was updated successfully, but these errors were encountered: