Publish current development version in some format that can be consumed by npm

[hlxid]

Description

It would be nice if we could publish the current development version. That way we can generate bundles in the cli that can use those and you don't need to add your bundle, that relies on a development version, to the lerna.json (like in skates-bundles).

Some ideas on how me might do this:

• push compilation results to a separate branch (force push, otherwise the repo might get too big)
• push compilation results to a separate repository (with history and the possibility of publishing feature branches that are not master)
• publish on the official npm registry with the next dist-tag (you get a email for each package publication with no opt-out, no please not)
• publish npm tarballs
• publish on github package registry (only viable if they figured out unauthenticated reads)

Not sure yet which route we're going with...

[vypxl]

An idea: What about Github build artifacts?
https://docs.github.com/en/actions/advanced-guides/storing-workflow-data-as-artifacts

[hlxid]

Might be an option but GH Actions Artifacts has to my knowledge no way to always get the latest version with a static url. You would need to always update the url to include the id of an artifact of a recent run.

[TimTechDev]

I would prefer option b)

push compilation results to a separate repository

[hlxid]

Yeah, that's propably the way to go in combination with e.g. GitPkg because npm can't include a sub directory of a repository.
Having the ability to test feature branches is also kinda nice.

[hlxid]

An advantage for publishing tarballs would be that we could publish the samples as tarballs too. We could then get them in the nodecg-io-cli in order to install them for production installations. We would still need to figure out how the TypeScript code can be built then, but we could more easily download the samples.

I don't really want to use an external service like GItPkg if I don't need to. I'm think for now we're going to do both: tarballs and the actual compilation results, so we can use what we want and still decide on one of them later. Unpacking the tarballs in the GItHub Actions step isn't too much of a hassle.