npm or pnpm?

[jgadsden]

Originally Threat Dragon used npm, and then it was migrated to pnpm in 2021

pnpm was chosen because it is fast on the download and install ... and we liked using it as it is marginally more forgiving than npm: we thought it looked fun and went with it

It has caused us some problems, for example moving from pnpm version 7 to 8, and it does have some downsides. It may be stopping us from implementing flatpak.

Should we migrate back to npm? It is not as bad as it sounds and does simplify our pipeline scripts

[jgadsden]

@sparticvs :
I don't think we should migrate back to NPM from PNPM just for flatpak. We can convert from Appimage into flatpak with relative ease, but IMO it's more about getting the pipeline fully assembled and tested before merging it into the upstream (aka here). I tried doing a very thorough approach with the flatpak on v1.6, but the issues I've been running into have more to do with electron

[sparticvs]

Just to provide a little more clarity in my position here. I don't think we should migrate solely for flatpak's sake.

I have a secondary concern (and this probably will show my current ignorance to how TD works) with having the package manager stick around - that is there is a likelihood that the package manager could be performing updates. I am of the mind that the user should be able to expect that Threat Dragon will continue to function regardless of patch state in the supply chain. I say this for a few reasons:

1. Even if a package has a vulnerability doesn't mean that TD is directly affected by the flaw
2. Users may be relying on this tooling for day-to-day work or work in domains that has strict configuration management controls (e.g. Functional Safety), and automatic updating would be a problem here
3. Flatpak's security controls could cause breakage that is harder to debug because the flatpak that someone downloaded is several iterations old, but the app version itself is current.

This does mean that the build pipeline would need to run regularly to ensure supply chain elements are up-to-date, but IMHO this is a better route to go.

All of this said, if pnpm is causing issues with other features that we'd like to deliver, maybe it's not worth the value of saving bandwidth to the npmjs repos and local disk space.

[jgadsden]

A pull request #638 is in draft form that implements migration from pnpm to npm
It can be closed if we decide to keep pnpm, or can be used to migrate to npm - there is still a bug in the SBOM though

[jgadsden]

I have resolved the conflicts in #638 and I suggest we go ahead with this.
The pipeline is not any slower using npm instead of pnpm and we can no longer require that pnpm is installed as a pre-requisite