[foldr]

But that doesn’t pin to a specific version?

[oasisaimlessly]

It does, in combination with a pinned nixpkgs commit, which you can find like this:

    ~/repos/nixpkgs$ git log --grep='nodejs.* 24.14.0' -1 origin/master
    commit 9c0e2056b3c16190aafe67e4d29e530fc1f8c7c7
    Merge: d3a4e93b79c9 0873aea2d0da
    Date:   Tue Feb 24 16:53:40 2026 +0000
    
        nodejs_24: 24.13.1 -> 24.14.0 (#493691)
    ~/repos/nixpkgs$ nix eval nixpkgs/9c0e2056b3c16190aafe67e4d29e530fc1f8c7c7#nodejs_24.version
    "24.14.0"
    ~/repos/nixpkgs$

[JamesSwift]

It does, but its implicit (and so may not be the exact patch version you have in mind). See my other comment for how to handle if you _do actually care_ about pinning to a specific version explicitly.

[foldr]

Doesn't that pin me to a particular versions of nixpkgs? That's fine if I only care about nodejs, but if I want to maintain particular versions of different tools, it won't work.

[JamesSwift]

Again, generally in other systems the full semver pinning is more of a crutch to get some 'reproducibility' that nix gives you out of the box at a much higher level. So, in general, people just pin to the major version in nix. But if you _really_ want the full semver pinning there are multiple options that I lay out in the other post. You can even patch the _actual nodejs source itself_ in reproducible/version-pinned ways.

[foldr]

I do want exact version pinning of individual packages. (As I said in my initial post, I’m aware that Nix advocates think that I shouldn’t want this.)

I’m not sure what other post you’re referring to. There’s one where you describe some approaches in broad terms, but as far as what the relevant devenv.sh config would look like, I’m none the wiser.

[JamesSwift]

You still are pinning to exact versions of packages (and in fact are pinning to specific shas / content hashes of the packages) but you are doing so implicitly by going this "path of least resistance". The only thing that will change what _exact sha_ you are pointed at is an explicit update by someone. There is no risk of someone running install on one box and someone running it on another and them getting different _exact versions_ (or likewise, in CI it also will be the exact same). And in general thats what people are trying to achieve on teams by pinning to full semver. So thats what I mean by its generally not needed on nix.

However, to actually address your question it would be something like this (with ruby also added for comparison of whats possible depending on the language ecosystem you are using)

  ```devenv.yaml```

  inputs:
    nixpkgs:
      url: github:cachix/devenv-nixpkgs/rolling
    nixpkgs-node:
      url: github:nixos/nixpkgs?rev=9c0e2056b3c16190aafe67e4d29e530fc1f8c7c7
    nixpkgs-ruby:
      url: github:bobvanderlinden/nixpkgs-ruby
      inputs:
        nixpkgs:
          follows: nixpkgs

  ```devenv.nix```
  
  { inputs, pkgs, ... }
  
  {
    languages.javascript = {
      enable = true;
      package = inputs.nixpkgs-node.nodejs_24;
    };

    languages.ruby = {
      enable = true;
      versionfile = ./.ruby-version;
      // alternatively
      // version = "3.2.4";
    };
  }

[foldr]

Thanks for the code.

Pinning by version number isn’t a crutch; it’s more a question of mental models. Most people find it more intuitive to identify a world by describing the things in it than to fix the states of the things by identifying the world where they have those states. Nix sometimes feels as if someone read Kripke and missed the passage about possible worlds being a figure of speech.

In other words, many of us don’t think that version numbers are a crutch to be used in the absence of a totalizing hash of the entire state of the universe. We actually think that version numbers are, for many practical purposes, better than that.