Add job to publish to GPR

[asbjornu]

Add a GitHub Actions job to publish the NPM package to the GitHub Package Registry.

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)
• If applicable, I’ve added docs and tests

Description of changes

As per actions/setup-node#243 (comment), an ephemeral scope can be set with npm init -y --scope ${{ github.repository_owner }} before npm publish is executed. This PR is an attempt to implement this.

[codecov-commenter]

Codecov Report

Merging #70 (843b343) into main (4bf8c9e) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #70   +/-   ##
=======================================
  Coverage   50.00%   50.00%           
=======================================
  Files           1        1           
  Lines          22       22           
  Branches        3        3           
=======================================
  Hits           11       11           
  Misses          9        9           
  Partials        2        2           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4bf8c9e...843b343. Read the comment docs.

[asbjornu]

To the best of my understanding, this seems to be working. Please have a peek at the published NPM package to see whether it looks fine or not.

[wooorm]

/cc @remcohaszing

[remcohaszing]

This is a VSCode extension, not an npm package. Are there any benefits of publishing a VSCode extension to an npm registry?

[asbjornu]

It's not that the NPM package itself is useful or meant for consumption, but since we can't publish to the VS Marketplace on every pull request, I think publishing to GPR is a cheap way to validate at least certain aspects of the package.

[wooorm]

How do you see this being used?

[asbjornu]

An NPM package will be built and published to GitHub Package Registry for every build, so we get some sort of validation of the package. It's not much, but better than nothing.

[wooorm]

If this is about building the package, then, doesn’t say npm test (or npm pack) do enough?
Or do you envision maintainers check each PR locally by installing each branch from GPR and testing it out?

[asbjornu]

I believe there is utility to being able to install non-stable releases of the package, yes.

[remcohaszing]

The extension is already built for each PR by the package job and can be downloaded from GitHub actions. The vscode-remark.vsix file can be installed manually.

Example: https://github.com/remarkjs/vscode-remark/actions/runs/1599128469

[wooorm]

That sounds like what you want to do is already possible @asbjorn? Or not?

[asbjornu]

No, upload-artifact performs precisely zero validation of anything – it's in use only to modularize the GitHub Actions. Doing npm publish performs validation and makes the package available through NPM. May I ask what harm is caused by merging this PR since I'm receiving so much push-back for it? :)

[wooorm]

On process

[…] since I'm receiving so much push-back for it? :)

PRs typically come with an argument for why they should be merged. This one did not. For more information, see the contribution docs on how to submit a PR, specifically the last point:

Write a convincing description of why we should land your pull request: it’s your job to convince us
— contributing.md

What you perceive as push-back I would call scrutiny, and expected scrutiny for that matter. The decision model used by the remark organization and the rest of the unified collective (and many other open source projects, such as Rust, Electron, and Node), is lazy consensus and consensus seeking.
The first part of that process is teasing out alternatives and figuring out whether something actually is needed.
For more information, see: https://github.com/unifiedjs/collective/blob/main/decisions.md.

May I ask what harm is caused by merging this PR […]

I think it’s best to think of it as the inverse: pull requests don’t get merged unless there is agreement that it is a welcome addition

On PR

Doing npm publish performs validation [...]

Can you clarify for me what validation is done by npm publish?
You mentioned “certain aspects” before, but my question on how npm publish differs from npm test or npm pack is as of yet unanswered.

[...] and makes the package available through NPM.

Am I correct in understanding availability through npm as unimportant, as you earlier said “It's not that the NPM package itself is useful or meant for consumption [...]”

[asbjornu]

What you perceive as push-back I would call scrutiny, and expected scrutiny for that matter.

Okay.

my question on how npm publish differs from npm test or npm pack is as of yet unanswered.

There are server-side validations performed with npm publish that can't be replicated with npm pack, afaik. I don't have all the details and can't find the will in me to perform the investigation required to ensure that we don't publish anything to GPR, because I don't understand the harm caused by publishing to GPR.

If there is no harm caused by npm publish and there is a benefit to npm publish, I have to wonder what is gained by spending hours discussing various avenues to avoid merging this PR. As a maintainer of this repository, this PR is going to make my life easier by making me feel a little bit safer knowing that future PRs are not going to screw up publishing to the VS Marketplace. I know npm publish is not the same as publishing to the VS Marketplace, but this is a low-hanging fruit providing some of the same checks and thus providing some of the same guarantees.

Am I correct in understanding availability through npm as unimportant, as you earlier said “It's not that the NPM package itself is useful or meant for consumption [...]”

"Unimportant" is an understatement. "Not significant" is more apt. It's a positive, although minor, byproduct.

[remcohaszing]

The main problem isn’t that publishing an npm package to the npm registry for each PR to apply such validations is a bad idea. The problem is that this isn’t an npm package. For example some differences are:

• npm uses .npmignore, vsce uses .vscodeignore.
• GPR package names must be scoped, VSCode extension names may not be
• npm uses .tgz files. vsce uses .vsix files.

Whatever validations are done by publishing to an npm regitry, likely don’t apply to a VSCode extension.

If you could give concrete examples or references of why this is a good idea, I’m definitely more open to it.

[wooorm]

and there is a benefit to npm publish

Please explain what the benefits or checks are. I personally have no knowledge of any additional checks that npm publish performs, and I can’t fine anything. This has been repeatedly asked now.

[asbjornu]

As I don't have the time to sift through the client and server side source code of npm publish and vsce publish to figure out how the former may compensate for the lack of the latter, I'll close this. But I'm going to investigate the possibility to do vsce publish for non-stable releases as support for that has just landed in the VSC Marketplace as per microsoft/vscode#15756.