Draft: Point Pulsar's first-party dependencies to NPM packages

[savetheclocktower]

This PR has one extra commit on top of the current HEAD of updated-latest-electron: one which updates package.json to use the published-to-NPM versions of superstring, text-buffer, pathwatcher, et al., and updates the imports themselves to reference the namespaced package names.

When I tried this locally earlier today, it revealed a couple of mistakes I'd made in the publishing process. But once I fixed those, everything seemed to work. So the next step is to open this PR and see if the binaries generated by CI also work out of the box.

I have procrastinated on one last item: updating the github package to use a newer version of whats-my-line that points to @pulsar-edit/superstring rather than superstring. For now I “fixed” this by using the resolutions section of package.json such that any attempts to import superstring by whats-my-line instead get @pulsar-edit/superstring. But I'll tackle the github package tomorrow or Tuesday. (Edit: Fixed this, I think.)

Testing

If you're on a platform that can use the CI-generated binaries (i.e., not Apple Silicon or ARM Linux), please download the artifacts and give it a try! If nothing explodes, that'll be a very positive sign.

[savetheclocktower]

Good news! After addressing some show-stopping and extraneous failures, I've now got this down to the expected number of CI failures.

The remaining handful of failing CI specs are known to be flaky and all pass for me locally on macOS, so I'm taking this out of draft.

[DeeDeeG]

I can confirm the CI failures are similar to those on the tip of the target branch for this PR. (And yeah they do seem flaky based on the differences in reruns.)

A lot of linter-generated whitespace changes from function() to function (), but eh... Oh well.

I am NOT familiar with the TypeScript stuff, but it seems small and bugfixy ... ? Rather than too ambitious or radical. At a glance looks okay?

Not sure what motivated regenerating yarn.lock entirely, but if the result works, then I suppose it's alright.

Not a huge amount is changed here other than bumping deps. Hopefully those dep bumps turn out to be in good shape, we'll see. But yeah, the return of semver and actual dependency version numbers in package.json, would you look at that.

Not my most informed review ever, but the PR doesn't look too crazy...

LGTM.

[savetheclocktower]

I regenerated yarn.lock because

• my original usage of the resolutions field to map superstring to @pulsar-edit/superstring somehow had the effect of putting it only at ./node_modules/superstring, making it unimportable from its original location;
• to get around this, I fixed the github package to use @pulsar-edit/whats-my-line so that there was nothing remaining that referred to a bare superstring without a namespace, then was able to remove that resolutions entry; but…
• after doing this, yarn install didn't result in any change. superstring was still in the wrong place.

As a sanity check, I did mv yarn.lock yarn.lock.old and re-ran yarn install. I realize now that I should've instead run yarn add @pulsar-edit/superstring; it wouldn't have changed package.json (the entry was already there!), but probably would've explicitly put superstring in the right place on disk.

I might revert the regeneration of yarn.lock and try it the correct way before landing this.

[savetheclocktower]

Nah! Tried it and it still didn't work. Despite the only references to superstring in yarn.lock being fully qualified @pulsar-edit/superstring references, superstring nonetheless exists at node_modules/superstring instead of node_modules/@pulsar-edit/superstring… but not when I nuke yarn.lock and install afresh. 🤷