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.
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.
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.
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.
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
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.
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.
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.
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.
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
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.
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.
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.