arcatek

5 ms·

1.
by arcatek 26d ago
Hold your horses, segregation was abolished in 1954, not sure US has ever been close from "the freest place on earth".
2.
by arcatek 2mo ago
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 bef
3.
by arcatek 3mo ago
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, bu
4.
by arcatek 3mo ago
It's not exactly unmaintained (we merged a couple of security patches in the past years), I agree that we should have do something about it. We'll be correcting this situation starting from the 6.x release, which we expect somewhe
5.
by arcatek 3mo ago
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: https://p.datadoghq.eu/sb/
6.
by arcatek 3mo ago
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.
7.
by arcatek 3mo ago
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
8.
by arcatek 4mo ago
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.
9.
by arcatek 5mo ago
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.
10.
by arcatek 7mo ago
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
11.
by arcatek 4y ago
> Huh? It queries whenever you stop typing. 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 t
12.
by arcatek 4y ago
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
13.
by arcatek 4y ago
> 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 "cle
14.
by arcatek 5y ago
Usually you setup a transpiler to target both. For example, my packages are bundled with rollup towards both cjs & esm: https://github.com/arcanis/clipanion/blob/master/rollup.conf...
15.
by arcatek 5y ago
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 a
16.
by arcatek 5y ago
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?
17.
by arcatek 5y ago
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, Core
18.
by arcatek 5y ago
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 o
19.
by arcatek 5y ago
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? https://docs.github.com/en/actions/reference/authe
20.
by arcatek 5y ago
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! htt
21.
by arcatek 5y ago
That's the article I used when I implemented exceptions in an LLVM-based compiler, so it's applicable to more than just GCC.
22.
C++ Exceptions: Under the Hood (2013)(monkeywritescode.blogspot.com)
115 points by arcatek 5y ago|111 comments
23.
by arcatek 5y ago
I know you're joking, but I worked in a startup where a massive effort was made to completely rebuild the 1.x website - both backend and frontend. It required a lot of work from everyone, and I remember we even stayed late more than a
24.
by arcatek 5y ago
We don't do support on HN, but if you really don't find information in our repository issues I'm sure our Discord can help. We publish all the Yarn packages to both the npm and GitHub package registries, so I'm certain i
25.
by arcatek 5y ago
That's not quite true, PnP has always been the default and we have no plans to change that. The only thing that changed is that when you migrate from v1, we automatically enable the node-modules linker. The reason for that is that PnP
26.
by arcatek 5y ago
We support it once you enable the `node-modules` linker (cf our documentation). It's a little slower and doesn't leverage some of the stability improvements brought by PnP (in short, you get a good old node_modules folder without
27.
by arcatek 5y ago
We use Yarn / VSCode / TypeScript (both to maintain Yarn and at work), so we are very invested in this use case. If something didn't work, we'd notice it quickly and the fix wouldn't take long!
28.
by arcatek 5y ago
I was the main developer back when the 2.0 was started (so, like, rc.1), but since then we grew and are now a team, with at least four very active contributors of similar expertise. I believe this is the greatest accomplishment of the v2.
29.
by arcatek 5y ago
Note that we don't recommend using both Yarn and npm: both have different feature sets, heuristics, and implementation details, and as a result your colleagues and you may have slightly different behaviors in development (on top of des
30.
by arcatek 5y ago
We maintain a set of automated benchmarks against Yarn 1/2+ (PnP and node_modules tracked separately), pnpm, and npm: https://yarnpkg.com/benchmarks The fastest are usually either Yarn PnP or pnpm. Note however that re

More ›