* Update glob-parent to resolve CVE-2020-28469
* Run audit tasks on Ubuntu runners (they are cheaper)
* Audit only production dependencies
That is, something that can actually affect users of this action.
I don't really want to be bothered with yet another "prototype pollution"
or "denial of service" in transitive dependencies of eslint.
* Audit dev-dependencies for critical vulnerabilities
That said, still audit development dependencies for critical
vulnerabilities if they come along. Hopefully, this should be rare.
Just another day in JavaScriptLand: some "HIGH PRIORITY" vulnerability
has been fixed (CVE-2021-23337). Update our package-lock.json version
too because npm wants that.
I'll probably use self hosted runners in a project and the Community
version of Visual Studio will be installed on those. This enables the
script to check for Community and Professional editions in addition
to the Entreprise one offered by GitHub.
The modification generates a kinda search map ordered by version then
by edition. It generates the batch script that runs vcvarsall.bat
on the fly given that search map.
"npm audit" started whining about moderate denial of service
vulnerability in a dependency of dependency of dependency
(eslint > espree > acorn). This is not really serious because
we use "eslint" only for development. However, red builds are not good
so bump the pinned version in package.lock. (Released versions are not
affected because they do not include eslint.)
It's not like we need any new features, but let's bump the versions
because we are in JavaScript land.
Also, run "npm audit" regularly, just in case a serious vulnerability
is discovered.
Now that I know how to write some simple action, let's make a stub
more complete. For example, I already know what inputs I would like
to handle for this action.