node-ffi-napi VS npm-package-repro

I actually came from AutoHotKey as well, specifically for the cross platform support!

I've found the dev experience with nut.js to be worlds ahead of AutoHotKey as well. You get to use a real programming language with proper modules, data structures, first-class functions, asynchrony, and have access to a vast ecosystem of third party libraries and tooling.

Some Windows specific APIs are easier to work with on AHK due to the collection of built-in functions specifically tailored for automation, but everything AHK is still possible with nut.js since you're just writing a node.js script and have access to libraries like https://github.com/node-ffi-napi/node-ffi-napi that can call native system libraries, with a bit more work involved.

> check out the Web X-Ray repo <https://github.com/mozilla/goggles.mozilla.org/>.

Thanks for example. Peeking a bit under the hood, it appears to be due to transitive dependencies referencing github urls (and transient ones at that) instead of semver, which admittedly is neither standard nor good practice...

FWIW, simply removing `"grunt-contrib-jshint": "~0.4.3",` from package.json and related jshint-related code from Gruntfile was sufficient to get `npm install` to complete successfully. The debugging just took me a few minutes grepping package-lock.json for the 404 URL in question (https://github.com/ariya/esprima/tarball/master) and tracing that back to a top-level dependency via recursively grepping for dependent packages. I imagine that upgrading relevant dependencies might also do the trick, seeing as jshint no longer depends on esprima[0].

I'm not sure how representative this particular case is to the sort of issues you run into, but I'll tell that reproducibility issues can get a lot worse in ways that committing deps doesn't help (for example, issues like this one[1] are nasty to narrow down).

But assuming that installation in your link just happens to have a simple fix and that others are not as forgiving, how is committing node_modules supposed to help here if you're saying you can't even get it to a working state in the first place? DO you own the repo in order to be able to make the change? Or are you mostly just saying that hindsight is 20-20?

[0] https://github.com/jshint/jshint/blob/master/package.json#L4...

[1] https://github.com/node-ffi-napi/node-ffi-napi/issues/143

NodeJS also has an FFI, where you can build a shared library (not limited to c++) and import it. Node-ffi-addon

I went a different route with my "malicious" NPM package. See if you can figure it out [1].

Years ago I played around with the idea of verifying that a npm package is the same code found from the source repo [2]. Because there is often a build step, that requires trying to reproduce the building of any arbitrary package, and flagging when there is any delta between the build output and the code distributed via NPM. In more reasonable package managers, this is true by default given that you provide the source code and the package manager builds it for you ... as opposed to NPM, which just asks for the executable code directly.

[1] https://github.com/connorjclark/totally-fair-rng

[2] https://github.com/connorjclark/npm-package-repro

I couldn't find the code, so I just started over. Haven't hosted it anywhere yet.

https://github.com/connorjclark/npm-package-repro