[dmitryminkovsky]

> Does anyone know of a good way to verify that a npm release matches what's on GH?

I'm not aware of any way to do this, and it's a huge problem. It would be great if they introduced a Docker Hub verified/automated builds[0]-type thing for open source projects. I think that would be the only way we could be certain what we're seeing on GitHub is what we're running.

Honestly it’s hard to believe we all just run unverifiable, untrustable code. At the very least NPM they could require package signing, so we'd know the package came from the developer. But really NPM needs to build the package from GitHub source. Node is not a toy anymore, and hasn't been for some time—or is it?

[0] https://docs.docker.com/docker-hub/builds/

[eyelidlessness]

This is ~solvable at a third party level. Nearly everything on NPM (the host) is MIT licensed or similar. When packages are published, run their publish lifecycle and compare to the package that’s actually published.

I don’t have the resources or bandwidth to do this, but it’s pretty straightforward +- weird publishing setups.

Edit: of course this doesn’t apply to private repositories but… you’re in a whole different world of trust at that point.

[hoten]

I started working on this exact problem a few years ago. Didn't get far, though, I think I stopped because I assumed there just wouldn't be any real interest.

[hoten]

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

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

[eyelidlessness]

Awesome! Thank you.

[arp242]

Doesn't npm have a facility to tell it to download releases directly from source? Most package managers have in one form or the other, but I'm not very familiar with npm.

To be honest I'm not sure if npm (the service, not the tool) and similar services really add all that much value. The only potential downside I see is that repos can disappear, but then again, npm packages can also disappear. I'd rather just fetch directly from the source.

This is how Go does it and I find it works quite well. It does have the GOPROXY now, but that's just an automatic cache managed by the Go team (not something where you can "login" or anything like that), so that already reduces the risk, and it's also quite easy to outright bypass by setting GOPROXY=direct.

[Zababa]

Deno (https://deno.land/), another runtime based on v8, has a system similar to Go, with local and remote imports https://deno.land/manual@v1.11.5/examples/import_export.

[dmitryminkovsky]

You can’t really fetch from git because for the majority of packages there is a non-standard build step that packages do not consistently specify in package.json, if at all. Packages on NPM are just tarballs uploaded by the author. Furthermore, what about transitive dependencies?

[arp242]

> what about transitive dependencies?

What about them?

As for unspecified build steps: this seems like a solvable problem. I would just submit a patch.

[Too]

Fetching from git is possible. The downsides are lack of semver, having to clone the full history of the repo, and having to clone the complete repo including files not needed for just using the lib, eg preprocessors, docs and tests.

[arp242]

I assume people use tags and such no? That gives you versions and you can just fetch it at a specific tag. Either way, this is very much a solvable problem.

A few docs and tests doesn't strike me as much of an issue.