Add profile marker check

[catatsuy]

Allow users to prevent nvm from automatically updating their shell configuration files by adding '# nvm completions' comment. This follows the same pattern as bun where the presence of the marker indicates the user wants to manage the configuration manually.

When '# nvm completions' is found in .zshrc/.bashrc, the installer will skip adding nvm initialization code, giving users more control over their shell configuration.

oven-sh/bun#7641

refs: #2153 #2076

[ljharb]

I'm a bit confused why a) this would be needed, when you can PROFILE=/dev/null and the install script won't modify your profile files, and b) why we'd want to follow bun's quite arbitrary and tricky to parse direction here.

[catatsuy]

Thank you for the comment. @ljharb

I understand that setting PROFILE=/dev/null works as a workaround, but from a usability perspective, I believe it's not very discoverable for most users. The issue here is not just about how to disable profile modification, but whether users are clearly informed and empowered to control it.

Ideally, I believe nvm shouldn't modify user profiles without explicit consent. But since this behavior is unlikely to be removed soon, providing a clear, documented, and non-destructive opt-out method like # nvm completions is a more user-friendly compromise.

This approach has precedent (as in bun), and while I agree it's somewhat arbitrary, it provides a familiar and minimal surface for users who just want to avoid automatic modifications without needing to dig into environment variables or wrapper scripts.

Happy to adjust the implementation or name of the marker if needed—my main concern is to make nvm a bit more respectful of user configurations by default.

[ljharb]

"I'm running an installer" is explicit consent, in all software i'm aware of. Directly below the place a user gets the install command, it says

attempts to add the source lines from the snippet below to the correct profile file

I totally agree that the PROFILE workaround is not discoverable or ergonomic; but that's because you're basically the second user in 15 years who's asked about this or been even remotely concerned about it.

I don't think "searching a profile file for a marker" is a reliable (and thus, ergonomic) approach either. Do you have an alternative suggestion? If so, perhaps an issue would make more sense to discuss it prior to a PR.

[catatsuy]

Thanks for the detailed reply. @ljharb

I agree that running an installer is a form of consent, but in practice, especially with shell one-liners (curl | bash), users may not fully understand that their shell profile will be modified permanently. The warning is there, but still, people tend to skip over such details.

You're right that this isn't a common complaint on GitHub. But I suspect that's partly because users either silently accept the modification or avoid using nvm altogether after one bad experience. This is a long-standing friction point that deserves more visibility.

I submitted this PR primarily to spark this exact conversation. If you prefer to move the discussion to an issue first, I’m happy to open one and link back here.

As for alternatives to a profile marker — I'm open to other opt-out mechanisms that:

• Don't require env vars in one-liners
• Are easy to discover and undo
• Don’t make assumptions about shell startup logic

Let me know if you'd prefer to continue in an issue — but I’d argue a PR is a perfectly valid way to initiate meaningful discussion, especially when the current behavior isn’t likely to change without code in front of us.

[ljharb]

We can certainly continue to discuss here, but code isn't really ever needed in order to decide a way forward :-)

nvm currently installs with a one-liner, that will work in a headless environment or not. An env var, or a command line argument, are the only ways I'm aware of to modify a one-liner for a "from scratch" setup. I'm not sure why FOO=bar <install script> is particularly worse than <install script> --foo=bar, personally.

As for making assumptions about shell startup logic, I'm also not sure how that's avoidable - we already assume it's a POSIX-compliant shell (or zsh); in order to be automatically sourced in new shells, we have to live in a profile file somewhere; in order to find the right profile file, we have to make guesses and apply heuristics (something we already don't do a perfect job of). Do you have a concrete idea that would improve things?

[catatsuy]

Thanks again — I really appreciate your detailed response. @ljharb

I think we’re possibly talking past each other a little, so let me try to clarify my perspective:

To me, the core issue isn’t about whether environment variables or command-line flags are more elegant — it’s about whether users can clearly and easily express intent to prevent profile modification, especially when they’re not aware it’s going to happen. The current mechanism assumes a level of understanding and intentionality that I don’t think reflects how many people use curl | bash installers in real-world situations.

Yes, I agree that in some sense, running the installer is “consent,” but it’s blanket consent, and .zshrc is a sensitive, often-hand-edited file. From a trust and UX perspective, I think it’s more respectful to err on the side of not touching it unless clearly allowed.

The idea behind the marker (# nvm completions) is simply to offer a minimal, zero-friction way for users to opt out of profile modification in the file itself — the same place the auto-edit would otherwise happen. Compared to using PROFILE=/dev/null, I believe it’s easier to discover, easier to reason about, and less error-prone, especially for less experienced users.

That said, if you’d prefer a more structured way like a --no-profile flag or something similar, I’m totally open to alternatives — I just want to make it easier for users to protect their profiles without having to dig into the script or read the full docs up front.

[ljharb]

Hmm.

So, if I take your perspective, you'd prefer that the install script not touch profile files by default, with an easy way to opt in to it - iow, the "safe by default" perspective?

In general I'm highly sympathetic to that, but I don't see "append some lines to the file" as particularly troublesome. Can you help me understand what problems it causes you to have it modify your zshrc by default?

[catatsuy]

Thanks, yes — you got it right. I’m asking for a “safe by default” approach. @ljharb

Here’s why I think changing .zshrc by default is a problem:

1. Surprise
   Many users don’t expect their config files to be changed just by running an installer. It can feel intrusive, especially if they didn’t read the full output or know what’s happening.

2. Breaks existing setup
   Some people write complex .zshrc files — with conditional logic, custom prompts, or tools like virtualenv. Adding lines in the wrong place can break things or cause weird bugs.

3. Version control issues
   Many users track their dotfiles with Git or sync them across machines. Auto-modifying the file adds noise to commits and can cause problems on other systems.

4. Harder to reproduce or audit
   If a tool changes config files silently, it’s harder to understand or rebuild the environment later. This is especially important for teams or shared setups.

I’m not against helpful defaults — I just think editing user files should only happen if the user explicitly agrees. Tools like git don’t do it, even though they are very widely used.

I’m open to other ways to solve this. I just want to protect users from surprise changes.