Latest version of vnu.jar

[deniak]

spec-prod currently fetches vnu from npmjs but @sideshowbarker suggested that https://github.com/validator/validator/releases/download/latest/vnu.jar is more reliable.

[sidvishnoi]

@sideshowbarker @deniak I'm exploring locking all dependencies in the GitHub action (#141 (comment)) in light of preventing breakages, stronger version control and potential security vulnerabilities.
Do we have a specific desire where we want the latest version of vnu and not a locked version? Is the npm version not in sync with latest releases?

[sideshowbarker]

@sideshowbarker @deniak I'm exploring locking all dependencies in the GitHub action (#141 (comment)) in light of preventing breakages, stronger version control and potential security vulnerabilities.

Yeah, that sounds like a prudent thing to do.

Do we have a specific desire where we want the latest version of vnu and not a locked version?

No such specific desire from me personally at least. I think it should be fine to just hardcode in a particular version of the npm package — I mean, whatever the latest version available happens to be on whatever day the code is changed to flip the switch over to locking in on a numbered version.

Is the npm version not in sync with latest releases?

Mostly. But due to the fact that npm package versions can’t be overwritten, then there’s always a possibility — on any given day — of that npm version released that day maybe being out of sync by one day’s worth of changes with the last “latest” GitHub release which went out that day.

To explain what that means and why it is: All vnu releases are done automatically by GH Actions — every time a push is made to the remote. And so, on any given day, because there may be multiple pushes that day, then there may also be multiple releases for vnu at GitHub that day — all of them un-numbered and just being identified as “latest“, with each essentially just overwriting the previous.

But because the npm package system somewhat requires numbered versions, and because the npm package-release system (unlike the GitHub package-release system) doesn’t allow overwriting a released version of an npm package, then that means that on any particular day, an npm package gets published only the first time any push is made to the project’s GH remote on that day — but if any subsequent pushes are made that day, they don’t get “pushed” to the npm version, while they do still cause the latest GH release to get updated (overwritten).

[sidvishnoi]

Thanks for the context, @sideshowbarker!

I wonder if vnu can publish to npm at the end of day as well, if there are changes since last publish..

[sideshowbarker]

I wonder if vnu can publish to npm at the end of day as well, if there are changes since last publish..

Yeah, good idea — I reckon I could set up some kind of cron job (under GH Actions) to do that

[sideshowbarker]

Incidentally, in other news (and for the record here) — I’m making some (hopefully non-breaking) changes (just additions, really) to the install stuff and API for the vnu-jar package. See validator/validator#1972

As documented in the updated npm.md there (the source for the package README), the changes are that the package will:

1. Run a postinstall step which — if it finds no java command in the user’s environment during install — will then automatically install a (Node.js-local) Java runtime environment, in node_modules/.cache/vnu-jar/java/).
2. Expose an npx-runnable vnu command — for doing, e.g., npx vnu index.html.
3. Expose an additional new check() function, so that code can just do this:

   const { vnu } = require('vnu-jar');
   const source = process.argv[2];
   if (!source) {
       console.error('Usage: node vnu-check.js <source>');
       process.exit(1);
   }
   (async () => {
       try {
           await vnu.check([source]);
           console.log('✅ No problems found!');
       } catch {
           console.error('❌ Problems found.');
           process.exit(1);
       }
   })();

But, as far as I can tell, none of those changes should actually affect spec-prod at all. Specifically:

• spec-prod wouldn’t need to use the { vnu } export and check() function, but could instead just keep using the default export (to get the vnu.jar path)
• because spec-prod running under CI already installs a Java environment — with a java command — the new postinstall step will essentially just be a no-op for spec-prod

Of course if we wanted to switch spec-prod to using that new API, I guess we could — but it’s really just intended for use cases where we don’t know ahead of time whether there’s already an installed Java runtime in the environment. But since with spec-prod, running under CI, we can guarantee that a Java runtime is already installed — before npm install vnu-jar gets called — then it seems like there’d be no real need/benefit for spec-prod to switch to using that new API.