Packages are typically different once published than they were inside their original repositories. Call it transpilation, build, compilation, packaging, etc, most popular projects require some level of support for dynamic code execution before reaching their usable state.
As much as I'd have liked Git to be a viable option compared to centralized registries, last couple of years demonstrated running arbitrary commands during install is too much of a risk for it to work at scale.
As mentioned in the issue you link the problem comes from third-party packages with non-deterministic build scripts in git dependencies, or files on disk being actually different (although I guess we could at least try to normalize crlf, but as you can guess it will break someone).
I don't doubt that 3.x probably has worst perfs (it's almost two years old now), but just to clarify we closely track performances and Yarn and pnpm and pretty much on similar level:
Eh, easy to say. Remember how Sourceforge started shipping ads in binaries people downloaded? If you think failing was the worst scenario, you lack imagination.
Of course. Modern Yarn releases (4.x) are deterministic to a fault and you can rely on it to have a consistent behavior across your whole team. As for feature-wise I'd say it's a lot of small details that together add up once you grow used to them.
The next major release will keep pushing in that direction with both better performances and features we couldn't implement until now due to their reliance on said perfs improvements.
Curious how you did this; I looked into that couple of months ago but even with custom hooks the Python injection points seemed to limited due to the internal resolution cache.
Isn't Godot a little ill-designed to work well with LLMs? for example I ended up a couple of times with incorrect tres files, and letting the llm generate IDs feel a little fragile.
It's not about the package manager, it's about the runtime. Python isn't able to support this pattern with its resolution pipeline, so package managers have to resort to do the work to dedupe versions.
By contrast Node.js has built-in capabilities that make this possible, so package managers are able to install multiple versions of the same package without that issue.
That's relatively infrequently - TabNine offered me accurate completion while still writing my code, whereas with Copilot I not only have to wait for it to return the answer, I also have to hope it knows an answer. If it doesn't, too bad, lost time for nothing.
The article doesn't go into how to integrate TypeScript in the monorepo for development - what we do on the Yarn repository is that we point all the package.json `main` fields to the TypeScript sources, then use `publishConfig.main` to update it to the JS artifacts right before being published.
This way, we can use babel-node or ts-node to transparently run our TS files, no transpilation needed.
> If there are clearly better algorithms, why not refactor npm and add them in experimental flags to npm
While node_modules has many flaws, in the current ecosystem all modes have their own pros and cons, and there isn't a "clearly better" algorithm: node_modules has less friction, PnP is sounder, and pnpm's symlinks attempt to be kind of an in-between, offering half the benefits at half the "cost".
Like in many computer science things, it's tradeoffs all the way. Part of why Yarn implements all three.
However note that ESM in Node comes with drawbacks that prevent end-users from relying them in various situations. Those will be mostly solved once loaders become stable, but until then it's still advised to ship packages as both CJS and ESM.
Out of curiosity, how do transaction logs handle things like created_at fields, or randomly generated UUID, which rely on contextual data? Is the server time/rng seed faked for each replayed transaction?
To reiterate on what sibling comments said, I'm the one who spawned the discussion and implementation of Corepack, and npm remained largely out of it; the push mostly came from pnpm and Yarn.
Additionally, unlike other approaches, Corepack ensures that package manager versions are pinned per project and you don't need to blindly install newest ones via `npm i -g npm` (which could potentially be hijacked via the type of vulnerability discussed here). It intends to make your projects more secure, not less.
If they start to play with different rules, one of the hard fork remaining branches (or both) will be refused by everyone on the network and be worthless.
There's no telling whether it'd be the "hijacked" branch or the original one - assuming they control 50%+ of the mining power, there's a decent argument that the remaining miners would follow their lead if only to stay on the largest branch.
I was under the impression that the default temporary GITHUB_TOKEN for forked repos (which is what happens with PRs) were read-only. Isn't that the case?
It's public, but I doubt it still compiles against recent LLVM versions! I started it 8 years ago to get a better understanding how features like classes & operator overload would work in a JS-like language. It was really fun!
I remember that at the time there were very few resources on personality functions, even in the LLVM doc - I had to make a lot of research before finding your articles, which were extremely helpful!
I got reminded of them yesterday after someone pinged me on a Stack Overflow answer I made at the time, asking for an updated link; after I found your long-form article I figured it would be a good topic for HN as well :)
Twitter : @arcanis Website : http://arcanis.fr Email : [email protected]