(The latter would however not be the case for Titanic, I imagine.)

And in the best of worlds, that file format is simple enough to be understood in code reviews and scenarios where you want to generate them programmatically, not a huge incomprehensible json or xml.

I find this to be only even more important in 2026 where you could then also let a code agent generate the dashboard (any agent, any dashboarding software – no need for bespoke agent embeddings in the dashboard UI).

The mouse clickers can click their mouses and those of us (humans and machines) who prefers working with text files can do that. A good file format should take both into account.

Picked that one because it was supposedly the fastest, I liked the Github page and I will remember the name :) And I guess I was hoping for it to be a drop-in replacement for `parallel` interface-wise, which it turned out it was not, but my needs are quite minimal. I used to do:

ls | parallel 'echo {} && git -C {} fetch --prune --all'

Now I do:

( for i in $(ls); do echo git -C $i fetch --prune --all; done ) | rust-parallel -p

Anyone understands why they do this?

https://pnpm.io/supply-chain-security

While this explicitly calls out "postinstall", I'm pretty sure it affects other such lifecycle scripts like preinstall in dependencies.

The --ignore-scripts option will ignore lifecycle scripts in the project itself, not just dependencies. And it will ignore scripts that you have previously allowed (using the "allowBuilds" feature).

I feel it’s worth mentioning that there is a sense in which I think it might be a bad idea. It could be that you’d now be fixating some value that may be optimal right now, rather than benefiting from future improvements to the default settings. But it all depends, of course, on how close friends you plan to be.

I was more commenting on comments such as this one under Pkl:

> This is not a markup language. This is a full-blown programming language.

And under Nickel:

> Nice programming language. Not a markup language.

It's like he's saying "we should use markup languages for configuration, not programming languages", which I don't think he means.

Those often seem to generate a snapshot of the current state of the codebase that to me seem to be just begging to get out of date, often with references to specific files. I sometimes start out with them and remove a bunch of stuff, or I just start empty and add things as they appear to be needed.

What’s your strategy on these?