Alternative bootstrap and/or building

[mauricioszabo]

One of the main pain points of people wanting to join the codebase is how to start hacking the editor: ./script/bootstrap expect a really old version of Node.JS, even considering that we can run the editor on Node 16 without any change.

So, I decided to experiment if we can make things faster. The work is at the branch build-without-scripts and I had to use yarn although I would prefer to use pnpm (faster build, occupy less space on our disk, and also Yarn have telemetry by default) because npm was failing in interesting ways without even a stacktrace to check what's wrong.

For building, I decided to try electron-build. So, everything 100% works with some exceptions:

1. When developing the editor (with yarn start) packages can't be installed and/or checked. This is because apm needs to be on a specific part of the code. I worked-around this by adding an env var APM_PATH, but I'll discuss an alternative on a subtopic
2. Electron-build does not transpile packages. This is not a problem per se, but V8 snapshots (a way to boot Atom faster) does not work if you don't transpile anything. I benchmarked V8 snapshots on my machine, and they do give me 200ms faster load time for the editor, but when I actually opened both editors (with the snapshots and without) and compared then side-by-side, I could not see a single difference (I recorded my desktop and compared frame-by-frame). So maybe this is a non-issue
3. What IS an issue is that without transpiling, we can't actually run the Atom tests. I'm sure they are useful, so maybe it's a good idea to study if they can also work without transpilation (or with transpilation on-the-fly like some test runners do)
4. The final binary works, but it does lock the terminal on Linux (and probably on Mac too). Probably we'll need to tweak a little bit the instalation process
5. GitHub package is not working. I'm sure it's fixable - the package mixes ESM and CommonJS on the same file so if we fix these, it should work correctly
6. apm is not exposed on PATH

Now, what do we gain?

1. AppImage on Linux
2. DMG and PKG and other on Mac
3. Multiple builds on Windows, including portable app
4. Removal of 5,000 lines of code related to bundling things (code that we would have to keep, and that are sensible as some of it expected some file structure)
5. With PKG on Mac, I believe it's possible to create an universal package that runs both on M1 and Intel MacOSX
6. Auto-update can be managed by electron-builder, not some custom-made logic that Atom currently have.

Requesting for comments on these issues, to see if we want to proceed on this path :)

[mauricioszabo]

Alternative to APM_PATH

Honestly, I don't think running a binary and parsing results is a good way to check for packages inside Atom/Pulsar. So honestly I'm thinking about using APM (or PAPM for that matter) directly - using it as a library inside the editor.

That means we will not depend on apm being installed locally, and we also won't need to worry about PATH variables for APM, etc. We can make pulsar behave like apm based on some command-line interfaces: something like pulsar package instalk or pulsar package publish, etc - essentially, everything that starts with pulsar package gets routed to apm or papm (but as a library, not as a binary)