Better package version resolution accross meteor releases #13142
Replies: 3 comments 1 reply
-
I propose a "meteor-resolutions" section in package.json with the same syntax as for yarn’s resolutions where you can override package resolution on a global level. That solves not only this scenario but also other scenarios where the application developers while understanding the risks involved can override package sub-dependencies. The example here would be "meteor-resolutions": {
"mongo": "mongo@2.0.0-rc300.2"
} All transitive package dependencies on mongo would then resolve to mongo@2.0.0-rc300.2. |
Beta Was this translation helpful? Give feedback.
-
In the example logs, there's only two packages that are causing the conflict: Packages that have already been updated to use a pre-release version of mongo@2 shouldn't need that constraint to be updated until there is a mongo@3. For example, I think there's three main problems:
I think it is important for the first or second item to be solved before the official Meteor 3 release to make it easier for people to upgrade. |
Beta Was this translation helpful? Give feedback.
-
We have taken a note to consider the updates @zodern has suggested on this topic to promote a broader understanding of package version resolution and documentation, these is definitely worth for everyone. |
Beta Was this translation helpful? Give feedback.
-
Package version resolution is at the moment tied to the specific release of Meteor.
Indeed, the 3.0-rc.1 doesn't point to the same version of packages than beta.6 or alpha.1
Here is the output I have when trying to upgrade to the last RC :
Several package versions are conflicting, BUT most of them have already been migrated to be ready for meteor 3, since you can see references to
-alpha300.18
or other-beta300
and-rc300
. However, at each bump of Meteor version, all this falls appart and we need to have a re-publish of all those packages or to clone locally to make the changes...This creates a bad DX and a lot of friction for someone willing to migrate to the RC and provide feedback about it. Also it makes it almost impossible to start a new project based on the betas or RC, because you need to clone and maintain dozens of packages to follow up on meteor releases.
I think this feeling is shared by others (see here the maintainer of universe:i18n explaining why they won’t publish a meteor-3 compatible version yet)
It would be great if the future package version resolution could be more flexible in order to simplify this.
Beta Was this translation helpful? Give feedback.
All reactions