Setup automated publishing to NPM

[confused-Techie]

This PR configures automated publishing of this package to NPM under @pulsar-edit/less-cache.

This is the demo attempt at finalizing how we will do this organization wide.

The one none-standard thing here is that the secret we are using NPM_PUBLISH_TOKEN has been added on an organization level.
Pros: This means we only have to manage and update a single token to handle all package publications. With that we could setup stricter expiration rules without demanding too much work to keep them valid.
Cons: This does reduce security by having the token be able to make changes cross all packages.

To mitigate the cons listed above, the token is only being allowed to selected repositories. Meaning we have to ensure that a repo is on it's list before being able to use the token. As of now this repository is the only one configured to have access to this token.

How to actually publish

You may notice that I didn't opt to publish on commits or PRs, I thought it'd be too much of a headache to require any contributors to keep to specific semantics of their commit messages. Instead it seems to make more sense to me that we publish on a release being created.

So if we want to publish a new version no code changes are needed, just create a new release on the releases page. This does require that you've also updated the version in the package.json of the repository.

@savetheclocktower

[savetheclocktower]

It looks great.

How is a release actually created? Do we initiate it through the GitHub web site, or does it ever happen implicitly according to rules (e.g., when a new tag is pushed)?

[confused-Techie]

@savetheclocktower With this current framework the release would be created manually via GitHub's website.
But if we want we can make it automatic when a new version is pushed.

Maybe that'd be something good to add in:

• If a new version is added in the package.json then we create the release automatically
• If a new release is created then we automatically update the version in the package.json

Then we only ever have to do one or the other. Does that seem like a good idea? Or should we leave it as is

[savetheclocktower]

Then we only ever have to do one or the other. Does that seem like a good idea? Or should we leave it as is

In the near term, I like the idea of doing it manually. Eventually we might want to automate it, but let's be careful about it.

[confused-Techie]

In the near term, I like the idea of doing it manually. Eventually we might want to automate it, but let's be careful about it.

Okay that makes sense to me, I'll leave it as is. Which requires that we manage the version in the package.json and create the release via GitHub's website

[savetheclocktower]

OK, so next steps sound like:

• Land this PR
• Change the name in package.json to @pulsar-edit/less-cache (never mind, that's already part of this PR) and bump the version number (optional, I suppose, since we're changing the publishing target)
• Create a manual release
• Verify it was deployed correctly

If so, then we can pick one of the packages on this list and open a similar PR to set up the publishing CI infrastructure.

[confused-Techie]

@savetheclocktower That sounds perfect to me!
Except in this one instance we can probably skip the manual release, and just manually trigger the workflow, since we've already created releases for this repo, that will be used to publish the newest version.

But I'll do that now and verify that everything has been published properly, and if so, I'll get started on some of those other repos.

Thanks for taking another look at this one and providing some implicit approval!