[pulsar-next] Get specs passing

[savetheclocktower]

Fixes #6.

---

Clearly we need to clear out the cobwebs in this repo! I was only able to npm install using Node 20 (rather than something newer), plus I needed to update the electron dependency and skip linting and documentation generation.

Also, there are a lot of test failures — about half of them because text-buffer issues a deprecation warning for something that is routinely done in the text-buffer test suite! But that can be tackled later. My goal here is just to get the MarkerLayer specs passing so I can, in turn, get the TextEditor specs passing in PulsarNext.

[savetheclocktower]

OK, this PR should make it so that all the specs pass with the PulsarNext versions of pathwatcher and superstring.

In pathwatcher's case, this test suite helped me find a couple of lingering race conditions in pathwatcher — for instance, trying to unwatch a path after all watchers had been stopped. (This branch is now consuming a version of pathwatcher that's several commits ahead of what's used by pulsar-edit#updated-latest-electron, but I'll fix that shortly.)

In superstring’s case, a couple of times I thought that I'd have to go in and make some small tweaks, but they turned out to be misuses of superstring that I was able to correct in this repo.

And there was one line that got omitted during (I assume manual) decaffeination of text-buffer.js that was causing a spec to fail — I restored the line and that fixed it.

[confused-Techie]

@savetheclocktower I'd love to see this one merged, think you could add a quick:

on:
  - push:
    - branches: ['master']
  - pull_request:

To .github/workflows/ci.yml so we can see these passing here rather than setting up locally?

[savetheclocktower]

Too scared!

Kidding. I'll make that change today.

[savetheclocktower]

OK, I've run into a number of potholes that I can only guess are due to my general unfamiliarity with GitHub Actions. You can see the commit history here as I tried a number of strategies, and the result is that the Ubuntu tests produced failures that I don't see locally on macOS. I'd settle for getting both jobs to run to their entirety even if one of them fails, but I can't immediately figure out how to do that.

@DeeDeeG, is there anything obvious I'm missing here?

[confused-Techie]

Sorry I sent you down that rabbit hole then.
I'll try to see if I can get them running locally so we can merge the PR, but beyond that we may need a more comprehensive look at CI to get it running in it's own PR.

I don't see anything that stands out immediately to me other than super old versions of the tools used to install NodeJS, but can't imagine that'd be the source of our issue.

[confused-Techie]

I'll add that I was able to confirm tests are passing successfully on both master and savetheclocktower:pulsar-next (for this repository).

So I can say confidently that this PR doesn't seem to break anything we test for.

For future reference if it helps for setting up CI here, I did use my Pulsar dev environment, which is on NodeJS v16.20.0 and I'm on Windows 10.

[savetheclocktower]

This branch is meant for PulsarNext, which is on Electron 30, which runs on Node 20.11.1 — so my goal was to get them to pass on that Node version. And I imagine that's why CI (on master) was pointing at Node 14, since that's what Electron 12 runs on.

I'm confused by the errors I was getting about Visual Studio — I imagine that Windows images have those sorts of tools installed, so I'm sure there's something trivial I'm not seeing.

[DeeDeeG]

I'd settle for getting both jobs to run to their entirety even if one of them fails, but I can't immediately figure out how to do that.

Ah, this needs matrix strategy fail-fast: false. https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast We do that at core repo.

Example diff:

  Test:
    strategy:
+     fail-fast: false
      matrix:
        os: [ubuntu-latest, macos-latest]
        node_arch:
          - x64
    runs-on: ${{ matrix.os }}

(The default fail-fast: true for job matrices seems unexpected and frustrating IMO, but alas, it is probably one of those "not gonna change it out from under people now" things.)

---

Edit to add: We can potentially mark the Windows job to run with failures allowed, so we can try it without failing the whole workflow status, if that's desirable... Such as while still debugging what's wrong with it.

https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#example-preventing-a-specific-failing-matrix-job-from-failing-a-workflow-run

[DeeDeeG]

This should allow e.g. the macOS matrix job to proceed if the Ubuntu job fails, for whatever reason.

Suggested change

	- x64
	- x64
	fail-fast: false

(I hope I got the indent level right...)