[zdc1]

The other thing that keeps coming up is the github-code-is-fine-but-the-release-artifact-is-a-trojan issue. It really makes me question if "packages" should even exist in JavaScript, or if we could just be importing standard plain source code from a git repo.

I understand why this doesn't work well with legacy projects, but it's something that the language could strive towards.

[embedding-shape]

> I understand why this doesn't work well with legacy projects, but it's something that the language could strive towards.

Why wouldn't that work well with legacy projects? In fact, the projects I was a part of that I'd call legacy nowadays, was in fact built by copy-and-pasting .js libraries into a "vendor/" directory, and that's how we shipped it as well, this was in the days before Bower (which was the npm of frontend development back in the day), vendoring JS libs was standard practice, before package managers became used in frontend development too.

Not sure why it wouldn't work, JavaScript is a very moldable language, you can make most things work one way or another :)(

[crab_galaxy]

`vendor/` folders give me the worst developer PTSD :p

6 conflicting versions of jquery, and you know every single one of them was monkey patched, cemented into the codebase forever.

[EMM_386]

This might make things worse not better.

Yes - the postinstall hook attack vector goes away. You can do SHA pinning since Git's content addressing means that SHA is the hash of the content. But then your "lockfile" equivalent is just... a list of commit SHAs scattered across import statements in your source? Managing that across a real dependency tree becomes a nightmare.

This is basically what Deno's import maps tried to solve, and what they ended up with looked a lot like a package registry again.

At least npm packages have checksums and a registry that can yank things.

[auxiliarymoose]

You can just git submodule in the dependencies. Super easy. Also makes it straightforward to develop patches to send upstream from within your project. Or to replace a dependency with a private fork.

In my experience, this works great for libraries internal to an organization (UI components, custom file formats, API type definitions, etc.). I don't see why it wouldn't also work for managing public dependencies.

Plus it's ecosystem-agnostic. Git submodules work just as well for JS as they do for Go, sample data/binary assets, or whatever other dependencies you need to manage.

[fishpen0]

> But then your "lockfile" equivalent is just... a list of commit SHAs scattered across import statements in your source? Managing that across a real dependency tree becomes a nightmare.

The irony is that this is actually the current best practice to defend against supply chain attacks in the github actions layer. Pin all actions versions to a hash. There's an entire secondary set of dev tools for converting GHA version numbers to hashes

[S04dKHzrKT]

This is where attestation/sigstore comes into play. Github has a first-party action for it and I wish more projects would use it. Regarding javascript specifically, I believe npm has builtin support for sigstore.

* https://docs.github.com/en/actions/concepts/security/artifac...

* https://www.sigstore.dev/

* https://github.com/actions/attest