DeeDeeG
commented
1 year ago Thanks for the review!
And by the way, with forking jasmine-focused, I mean doing so with the sole ambition of updating the way jasmine-node is specified in package.json from git+https:// to just https://. Should be a one-line change of removing four characters, if I'm picturing it right, just off the top of my head. This has come up as an issue I don't know how many times over at upstream and the atom-community fork.
Good news: the absolute newest npm versions appear to cope with it the git+https:// stuff just fine, so maybe it's just npm 6.x that's affected. And npm 6 won't be supported forever, so this won't be an issue forever even with no forking. But uh, getting kinda sidetracked on this tangent. I can propose it in another PR if I get around to it.
Anyhow... Merging this!
Note: I'm not sure why I can't write concise technical stuff lately, but this is a few very minor changes to make CI start passing on Windows again.
(Feel free to not read all that I've written here, because it is honestly a lot to read, and kind of an unnecessary level of detail. A bit of a brain dump. It probably takes less time to read the entire diff and commit messages than this massive PR body.)
This does a couple of things, essentially just to play whack-a-mole with fixing install errors in CI:
jasmine-nodeis specified (as an indirect dependency under thejasmine-focusedpackage...) using an GIT+SSH:// URL schema, which fails extremely often in various environments (especially CI), and confuses npm tooling extremely often and fatally, with poor and cryptic error messages being generated that are not very helpful.ssh://in package-lock.json, it should be replaced with the equivalenthttps://URL ASAP to prevent this sort of issue from happening again in the future. Sadly, any large amount of lockfile churn will tend to reintroduce thessh://stuff again...jasmine-focusedjust to update its package.json to stop specifying its dependency onjasmine-nodewith a weirdgit+https://schema URL... (here.)check-latest: trueoption for actions/setup-node, so we always get the latest patch versions of the Node LTS versions we specify. These Node patch-level updates also occasionally include patch-level bumps of Node's bundled npm as well, occasionally.package-lock.jsonused by npm 6.x. I would humbly suggest we decide on either lockfile v1 (npm 6.x) or lockfile v2 (npm 7.x or 8.x)... or even lockfile v3 (npm 9.x! which I recently learned exists... Sigh.)This PR is a follow-up to https://github.com/pulsar-edit/ppm/pull/11.