Hacker News: jdxcode

New comment by jdxcode in "Deno 2.9"

jdxcode — Thu, 25 Jun 2026 17:42:13 +0000

I think node already does this (sans AI), idk where the code lives but deno could probably just use the same list of repos

New comment by jdxcode in "Show HN: Nub – A Bun-like all-in-one toolkit for Node.js"

jdxcode — Wed, 24 Jun 2026 22:18:31 +0000

I agree that it sucks not being able to have comments in package.json, but I think it's the right call to not adopt something like jsonc. It would break so much tooling at this point I don't think it would be worth it.

New comment by jdxcode in "Pull request limits are cutting down the noise"

jdxcode — Wed, 24 Jun 2026 21:18:03 +0000

Your proposal wouldn't help me at all. I wouldn't say that the problem I'm having is even "spam" per se. (For context I receive hundreds of PRs each week across my OSS projects like mise)

In my case I sometimes get a flurry of PRs from over-exuberant contributors, not necessarily low quality even! Using this I can at least put some back-pressure on that and help keep things more fair across my contributors.

New comment by jdxcode in "Migrating from GNU Stow to Chezmoi"

jdxcode — Thu, 18 Jun 2026 21:38:53 +0000

Considering nothing in that reply criticized nix you’re certainly wrong. I don’t hesitate to share my opinions on nix anytime (just like nix users themselves) so I’d have no reason to be coy about my criticism.

tfrancisl was polite (even though I arguably wasn’t in the beginning) so I felt it important to return the favor.

New comment by jdxcode in "Migrating from GNU Stow to Chezmoi"

jdxcode — Thu, 18 Jun 2026 21:16:59 +0000

ALL mise features are experimental until the design is finalized. I don’t do breaking changes except in exceptional circumstances with a long procedure, so experimental means I have the liberty of making them in any release. It is not at all any marker of quality. That said, in practice I don’t make them often.

I’d argue it’s a good time to play with features since if you have any ideas on how it might better fit your workflow I still have the ability to change the design before it’s largely frozen.

New comment by jdxcode in "Migrating from GNU Stow to Chezmoi"

jdxcode — Thu, 18 Jun 2026 20:18:09 +0000

I always like to mention rcm. It's not a popular one but I tried probably 10 managers before it and much prefer it to the competition: https://github.com/thoughtbot/rcm

New comment by jdxcode in "Migrating from GNU Stow to Chezmoi"

jdxcode — Thu, 18 Jun 2026 19:52:48 +0000

I am genuinely confused. Are you saying dotfile managers need to be more complex? Or that nix's problem space is the only solution for the things in nix's domain? (of which dotfiles are just one—via home manager)

I thought it was the former but "just pulling a precompiled, dynamically linked binary and hoping it works" makes me think we're not on the same page since to me that has nothing to do with dotfiles.

New comment by jdxcode in "Migrating from GNU Stow to Chezmoi"

jdxcode — Thu, 18 Jun 2026 19:48:09 +0000

it's dependency free. You don't even need brew to install brew formulas.

The "exception" to that are linux package managers like apt-get and dnf which it calls under the hood. I think can't be an actual issue since it's not like you would ever use ubuntu/redhat without their system package manager installed.

New comment by jdxcode in "Migrating from GNU Stow to Chezmoi"

jdxcode — Thu, 18 Jun 2026 19:43:19 +0000

The problem with mise managing its own version is perf. I don't want a shim that has to read config files to exec the right version.

I would make use of min_version. It's not perfect, but will at least help bring laggards along.

New comment by jdxcode in "Migrating from GNU Stow to Chezmoi"

jdxcode — Thu, 18 Jun 2026 19:40:57 +0000

how nix-pilled do you have to be to think that nix is the "only real solution" to dotfile managers?

New comment by jdxcode in "Migrating from GNU Stow to Chezmoi"

jdxcode — Thu, 18 Jun 2026 19:26:25 +0000

Haven't looked into it but agents are so good at this I bet it'll be trivial to add

New comment by jdxcode in "Migrating from GNU Stow to Chezmoi"

jdxcode — Thu, 18 Jun 2026 19:06:14 +0000

It’s quite new but I’ve been cooking up some new bootstrapping features with mise which people may find relevant here: https://mise.jdx.dev/bootstrap.html

It’s for things like dotfiles, apt/brew packages, and LaunchAgents/systemd.

EDIT: I feel a little bad having hijacked this, as someone that hears a lot of opinions about devtools I can definitely say chezmoi is a darling of the community and I highly recommend checking it out.

New comment by jdxcode in "Bringing down my ZSH load times from ~3.1s to ~230ms"

jdxcode — Wed, 17 Jun 2026 20:53:08 +0000

mise isn't, and has the advantage that you don't need to build your own lightsaber with direnv and nix.

New comment by jdxcode in "Show HN: Homebrew 6.0.0"

jdxcode — Sat, 13 Jun 2026 13:18:33 +0000

doesn't aqua:docker/compose just work? it does for me

New comment by jdxcode in "Show HN: Homebrew 6.0.0"

jdxcode — Thu, 11 Jun 2026 18:22:24 +0000

mise kind of supports dependencies, just not in the way people expect coming from any other package manager. The dependencies in mise are not automatic and all of them need to be manually defined. They're to get around ordering issues since mise installs in parallel, e.g.: if you use "pipx:black" you need to wait for python to finish installing. (This is the "depends" option on tools")

This is intentional as mise is not intended to be a full bootstrapping solution in the way homebrew/nix is, mise is designed to be an overlay on top of existing systems. So if you want to manage python with brew and black with mise it basically just works without extra configuration. I think this design decision has paid off in spades. It sounds like a drawback but at the end of the day it's probably the #1 reason users find mise easy to use.

New comment by jdxcode in "Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised"

jdxcode — Thu, 21 May 2026 17:29:46 +0000

1. the supply chain attacks I've seen are naive. They just leverage postinstall hooks. Malicious code also needs to be executed, not simply installed, so it's a lot less likely that an exploit would happen compared to postinstall since it can't just be buried in a transitive.

2. aube does the same. This is an extra level of protection if you've already whitelisted a package

New comment by jdxcode in "Postmortem: TanStack NPM supply-chain compromise"

jdxcode — Tue, 12 May 2026 01:47:53 +0000

In aube you get all this out of the box plus a lifecycle jail (next MV will have that on by default) and defaults to trustPolicy=no-downgrade (would not have helped here but still a good default).

It has the strongest security posture of any node pm.

https://aube.en.dev/security.html#jailed-lifecycle-scripts

New comment by jdxcode in "Going Full Time on Open Source"

jdxcode — Thu, 07 May 2026 00:16:46 +0000

Feeling is mutual!

New comment by jdxcode in "Going Full Time on Open Source"

jdxcode — Thu, 07 May 2026 00:16:03 +0000

it was definitely a risky move, env vars are not perfect for this use-case (varargs is awkward) but I'm happy I went with the file tasks setup and the magic comments anyways. It's nice that you're not working in bash-inside-yaml or coming up with a new file type. It is just bash.

New comment by jdxcode in "Going Full Time on Open Source"

jdxcode — Wed, 06 May 2026 23:54:35 +0000

I'm glad you're seeing it this way and finding value in it, this was very intentional. I wasn't happy with the status quo with all of the other tools in this space (nix, bazel, buck2, etc) that all force you to adopt everything from day 1. I think of mise as an overlay on existing systems, not a system in itself.