Review version constraints for production yarn dependencies

AFAICT the scope of this issue is to change all entries in core/package.json to only allow patch-level changes.

We have two choices to do that:

1. ^x.y.z to ~x.y.z
2. ^x.y.z to ^x.y

Since core/composer.json does the latter, I think we want the same here.

So the caret thing doesn't do what the IS is after.

"@babel/core": "^7.0" => this would make it possible to update to 7.17 without problem. I think what the IS is after is that we can only update to 7.0.1 with the version constraint.

What would work with regard to the IS is either: 7.0.x or ~7.0. It will introduce quite a bit more changes to packages.json since JS are pretty fast with releasing minor releases but should be safer.

This is at least major; borderline critical because we need to update 9.3.x and 9.2.x for security updates again, and yarn upgrade on 9.3.x or 9.2.x introduces a number of minor version updates that we should avoid if possible.

Indeed, option 2 is irrelevant. Only option 1 allows for patch level updates (stay within major.minor (x.y.*)).

Same thing for ~x.y, which is equivalent to ^x.y allowing you to stay within major (x.*.*).

Suggest to only use ~ for patch level updates (~x.y.z), use ^ for minor updates as well as patch level (^x.y.z)

went for the 1.2.x format, pretty self explanatory compared to ~ and at least we don't "lie" on the patch version number with what's in the package.json and what is actually installed.

Was on the fence about updating all of the things, i think i'll put them back to previous minors, they probably deserve their own issues.

One thing we should make sure of is that we increase the minor constraint to at least whatever is in the lock file for each branch. 10.0, 9.5, and 9.4 should get the latest minor. 9.3 and 9.2 should get the current minor in the package .json. This might result in minor downgrades in the lockfile for some dependencies, but probably that is less disruptive than minor updates being a hard requirement in the production branches.

It looks like the latest MR is already addressing that at least for Babel but we should make sure on a case by case basis that we do so everywhere.

Don't we need to rebuild all of the assets also?

updated the MR and patch to only update production dependencies

didn't touch at "@popperjs/core": "^2.9.2 <2.11.0", don't remember what that was about.

update tests for 9.3.x

I actually looked the syntax + meaning up before writing #2, and apparently still got it wrong! 😅 (It doesn't help that npm and composer handle ~ constraints differently 💩)

I do VERY strongly agree with:
went for the <code>1.2.x format, pretty self explanatory compared to ~

→ especially given the fact that npm and composer interpret these differently.

One thing I'm surprised to not see asked yet: why do we use a different kind of semver constraint for PHP dependencies than for JS dependencies? 🤔

That seems worth documenting 🤓

(But not sure where, since JSON cannot contain comments.)

The changes in https://www.drupal.org/node/2996785/revisions/view/12615848/12634473 are fine, but they do not yet document the rationale behind the different semver constraint concerns.

I'm thinking about the next core contributor who passes by and starts wondering just like me why we handle upstream dependencies differently depending on whether they're PHP or JS ones.

I'm not certain https://www.drupal.org/about/core/policies/core-change-policies/frontend... is the best place for that. I don't know if there is a good place for that.

Oh, definitely not saying that should be blocking! I just think that it's important for Drupal core security's sake that we clearly document the rationale for differing strategies in dependency management, to reduce the bus factor 😅

Speaking of which: I feel comfortable RTBC'ing this one, after having seen so many smart eyes on it. Let's land it, one less worry for shipping 9.4 then 😊

reroll for 10.x

#25 is double the size of #15. Why? 🤔

+++ b/core/core.libraries.yml
@@ -7,10 +7,10 @@ internal.backbone:
   remote: https://github.com/jashkenas/backbone
-  version: "1.4.0"
+  version: "1.4.1"

@@ -1027,10 +1027,10 @@ picturefill:
 popperjs:
-  version: "2.11.2"
+  version: "2.11.5"

@@ -1078,10 +1078,10 @@ internal.underscore:
   remote: https://github.com/jashkenas/underscore
-  version: "1.13.2"
+  version: "1.13.3"

Just making note of the prod dep updates (10.0.x).

Meanwhile, I realized this did not get backported to 9.2.x. Hopefully the other issue didn't include accidental minor updates for that branch. (I did review for that, but the issue took all day so I might've missed somethig.) We should still consider backporting it.

9.5 and 9.4 have the same updates as #35. For 9.3.x it is is only Backbone and Underscore. (GitLab does not cp well.)

+  version: "1.4.1"
  license:
    name: MIT
    url: https://raw.githubusercontent.com/jashkenas/backbone/1.4.0/LICENSE
 

underscore:
  remote: https://github.com/jashkenas/underscore
-  version: "1.13.2"
+  version: "1.13.3"

Thanks @lauriii.

I diffed core/assets/vendor, core/package.json, and core/core.libraries.yml against 9.2.0 just to make sure there were no out-of-sync updates to the prod dependencies for 9.2.x in this or other commits.

I think we are safe not trying to backport anything further since 9.2.x only has 6 more weeks of support. We just need to be careful if there are any yarn dependency updates between now and then. Easy to forget @nod_'s cool update thing is 9.3.x+ only. :)

Release note worthy; belatedly tagging.