fix: use compatible syncpack configuration

[JamieMason]

Fixes #923

• Update .github/workflows/syncpack.yaml to use the same major version as package.json
• Removes "sameMinorNew": true config (does not exist in syncpack)
• Migrate config and commands to v14 (https://syncpack.dev/guide/migrate-v14/)

The below line of .github/workflows/syncpack.yaml installed the latest major version unconstrained, and a major semver breaking change update had been released since the time of writing.

google-cloud-node-core/.github/workflows/syncpack.yaml

Line 18 in 7feb4c8

- run: npm install -g syncpack

I hope this helps, thanks for trying syncpack.

/cc @sofisl

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[JamieMason]

The syncpack errors are genuine according to the current configuration, which is asking that dependencies be on the same MAJOR.MINOR but any PATCH:

protobufjs for example is used on 7.5 and 7.0

   5x protobufjs
      ✘ ^7.5.4 in packages/gax/package.json at .dependencies (SameMinorMismatch)
      ✘ ^7.5.4 in packages/nodejs-proto-files/package.json at .dependencies (SameMinorMismatch)
      ✘ ^7.5.4 in packages/proto3-json-serializer-nodejs/package.json at .dependencies (SameMinorMismatch)
      ✘ ^7.0.0 in packages/proto3-json-serializer-nodejs/samples/package.json at .dependencies (SameMinorMismatch)
      ✘ ^7.0.0 in packages/gax/test/test-application/package.json at .dependencies (SameMinorMismatch)

Others like puppeteer are flagged because a range of ^ would allow MINOR versions other than 24.0 to be installed.

   1x puppeteer
      ✘ ^24.0.0 → ~24.0.0 in packages/google-auth-library-nodejs/samples/puppeteer/package.json at .dependencies (SameMinorOverridesSemverRange)

I don't have enough knowledge about what policies you would want to use to be able to help much further, sorry. There is a getting started guide at https://syncpack.dev/ and docs on the different policies available at https://syncpack.dev/version-groups/.

[sofisl]

/gcbrun

[sofisl]

Hi @JamieMason, thanks for helping with this! I was playing around with syncpack more, and I think we're going to stop using it for a few reasons:

• It seems like it will prefer the local version of a library if it's in a monorepo rather than the version that's already stated. while that may be the (better) way of doing things, we currently don't link our dependencies in this monorepo together, instead they're all being pulled from npm. So maybe in the future when we live at HEAD, this would be great to have, but we're not there yet.
• It seems like syncpack bumps minor versions where applicable if it's compatible. I'd rather do this with renovate bot since it will do it separately for each dependency and will recommend an appropriate conventional commit, which ties into our releasing.
• it seems like syncpack doesn't differentiate between ~ and ^ during preservation yet (this is a minor thing)
  Ultimately I just wanted to use syncpack to point out if we were using a major version of a dependency that was incompatible with something else, but I don't want it to be a dependency management system and I don't want to pollute/obfuscate a bunch of dependency changes this way.

Anyways thanks for your help, I appreciate it!

[JamieMason]

No problem at all, thanks for feeding back @sofisl