Pulsar's CI Ecosystem

[confused-Techie]

For this post there's two major things I want to touch on about our Organization's CI Ecosystem:

1. The Current State of it
2. The Past State of it

Current State

We currently have a slight mix-mash of tools that I hope we can find the right ones to default to, or stick with going forward. The first and most major of my concerns is Package Managers.

Package Managers

We currently have a mix of yarn, npm, and pnpm used through different sections of our codebase, and while there are situations where this makes sense, for example the conscious choice to move from npm to yarn in the Core Editor for it's better handling makes sense and is a fine exception, but I'd like to see where we stand on what we should use with other packages going forward. As in what is the safe default?

Since currently here are the exceptions:

• pulsar-edit/pulsar: Uses yarn
• pulsar-edit/pulsar-edit.github.io: Uses pnpm
• pulsar-edit/package-backend: Uses npm

Then for everything else it's essentially up for grabs. Now personally when I first come into a repo I will likely be tempted to use npm as the default, since as far as I can tell it's the most popular, and most synonymous with developing on a platform like this, so also the most likely for a new dev to already have installed. That is of course unless there's a lock file within the repo that can inform me. But there are times when there are two or more lock files present, which makes it difficult to tell which is correct.

Test Platforms

While our testing status isn't the best, we do have consistent and a fleshed out testing method on pulsar-edit/pulsar with GitHub actions doing some tests on PR's, as well as CirrusCI testing on PR's then building our binaries.

But beyond that we don't have much set in stone here. Now obviously we need to do more testing, and test all the code we are actually using, but we will have to decide what the best way to do this is. Now on some codebases this can be simple, writing a simple GitHub Action that can run the built-in specs could hopefully work about half the time. But otherwise there are some repos that have code that requires to be run within the Core Editor. And in those cases we can likely find old CI GitHub Actions written that use action-setup-atom. Which while a fantastic tool won't continue to work for us. Which means we either have to find some way to mock the editor for these repos during simple tests, or build out this same tool but for Pulsar, and start using that ourselves.

---

Past State

Alright now to address the leftovers of CI tools we have to deal with.

Really going into any codebase within our Org and you will find many leftovers that we currently do not use.

I mean for example here's some of what you can find just on pulsar-edit/pulsar:

• .cirrus.yml
• .coffeelintignore
• .eslintignore
• .eslintrc.json
• .nvmrc
• .prettierrc
• coffeelint.json
• package-lock.json
• playwright.config.ts
• pnpm-workspace.yaml
• stylelint.config.js
• yarn.lock

Now as a first time contributor, with all of that it can easily be confusing on what's in use, and what's not.

Now in this case obviously we are using yarn.lock, and .cirrus.yml but as for the others I don't believe we are, and it stands to reason for me, that there's no purpose in keeping them around, and help avoid future confusion.

Additionally many of our README.md's list badges to Azure CI, or have configs for them all together.

But we should decide on what we would want to keep here, and as we work on a repo go ahead and remove what's left there that's no longer needed.

---

Summary

To summarize there's a few things that I think we need to address as a community:

• What is our 'Lingua Franca' or Default Package Manager to use across repositories?
• Where should we document the exceptions to the above conventions?
• How do we want to test our code?
• Do we feel comfortable deleting outdated CI files as soon as we see them?

[Spiker985]

So, I believe we're actually using yarn.lock, .cirrus.yml, playwright.config.ts, and .nvmrc.

• Playwright is what was used to rewrite some of the failing tests, and is marked as a dev dependency
• .nvmrc is the native way to define a version for use with nvm, so you don't have to run a command to use the proper version of node while in the directory

I believe that we wanted to move to pnpm due to it's speed and handling which is why the website uses it. However, I believe there were problems when we tried to migrate to it before for the primary repo.

I personally would be okay with deleting the the extraneous items, provided we do it in a single PR, because that's the point of a VCS - we can restore them at any time.

[Daeraxa]

I still have a PR open for .nvmrc (pulsar-edit/pulsar#71), as we are advocating using nvm in our build instructions it makes sense that we keep this to our recommended version.

[Daeraxa]

There should never be any guesswork as to how to install or build something. You mention having to work it out from the .lock files etc. but there should be no guesswork required, this should all be correctly documented either in the repo or on the website with a link to it from the repo. I'm really keen that this remains one of the best documented project out there as much as we possibly can. We can't say we are hackable if we can't make it easy for people to get started.

What is our 'Lingua Franca' or Default Package Manager to use across repositories?

As much as I like pnpm I honestly think yarn is the best choice, the electron-builder docs recommend using it over npm and also require "shamefully-hoist" to be set for using pnpm.
Also the main pulsar-edit/pulsar project should be our "leader" on this in that it is the most difficult and requires the most work to change to another package manager.

.nvmrc

I believe this should stay and should remain updated as per this open pr as we are currently recommending use of nvm to build the application. It allows us to actually keep the docs up to date by just giving instructions to run nvm use if we bump node versions by simply specifying it in this one file.

I will likely be tempted to use npm as the default, since as far as I can tell it's the most popular, and most synonymous with developing on a platform like this, so also the most likely for a new dev to already have installed

This should be a non-issue. If we specify node 16 as the minimum then it already comes with yarn and pnpm by default, they just have to be turned on with corepack enable.

[confused-Techie]

You have some fantastic points here. And in that case I totally advocate for using nvm. Since it makes our lives, and our users lives easier.

But exactly it shouldn't require any guesswork. But in some cases it does, since the documentation may not be there, and in those cases we either need to add it, and should probably remove the useless lock files that cause the confusion.

[DeeDeeG]

I personally have been "going with the flow" with however the repo was set up as when I got there, mostly for expediency.

I think when touching enough parts of the software ecosystem you will run into more than one package manager eventually. Trying to re-write feels like it would take longer than learning the new tooling once, after which point it is like riding a bike, you probably don't forget how to work with it. It is particularly diverse in these repos, though, so it would be nice not to have to learn new tech... Hmm.

I support the notion of simplifying. Something to chip away at over time, IMO, since doing it all at once would be a really big task unto itself. IDK, I'm lazy and very "go with the flow", so take with a grain of salt.

[confused-Techie]

Totally agree there. I don't think this is much of a go with the flow, but more to prevent bloat from appearing. So that someone doesn't work on a repo and introduce something new since it's there favorite. Since ideally we would only have to learn a new tool because it provides value to the repo. Like in the case of using yarn and pnpm on those repos. It provided actual value.

[DeeDeeG]

I do lean toward: Eliminate as many .files (and config files in general) as you can get away with (prefer and tend toward the default config if at all possible), use npm if you can, again because it's the default, also tolerate yarn 1.x because it is the most well-behaved JS package manager I know of, even moreso than npm. I would give that up for the defaultness of npm where technically possible, though.

My two cents and arbitrary personal opinion on preferred tech.