Admins will be upgrading ORNL GitLab Servers on Saturday, 16 May 2026, from 7 AM until 11 AM EST. Repositories will experience intermittent outages during this time.
@@ -22,6 +22,8 @@ The package is defined in `pkgs/development/compilers/factor-lang/wrapper.nix` a
The package also passes through several attributes listing the wrapped libraries and binaries, namely, `extraLibs` and `binPackages` as well as `defaultLibs` and `defaultBins`.
Additionally, all `runtimeLibs` is the concatenation of all the above for the purpose of providing all necessary dynamic libraries as "`propagatedBuildInputs`".
Lastly, `extraVocabs` is passed through as is for stacked composition, and the fully composed `vocabTree` is passed through as a store path.
This makes it easier for external plugins (e.g. for editors and IDEs) to refer to the Factor vocabulary roots.
- Node.js default version has been updated from 22 LTS to 24 LTS.
This introduces some breaking changes; Refer to the [upstream migration article](https://nodejs.org/en/blog/migrations/v22-to-v24) for details.
- The Factor programming language has been updated to Version 0.101 bringing various improvements to UI rendering and HiDPI support as well as support for Unicode 17.0.0.
Starting from Version 0.100, the Factor VM is compiled with Clang.
This brings along some backwards compatibility issues in the language further detailed [here](https://re.factorcode.org/2025/12/factor-0-101-now-available.html).
Additionally, the FUEL Emacs module is no longer part of the `factor-lang` package.
It is part of the MELPA package set for a while already and must be taken from there.
This *does not affect*`factor-lang` packages Version 0.99 and 0.100.
Using the official MELPA package now puts the burden of providing the path to `/lib/factor` in `factor-root-dir` on the user.
Make sure to use the `extraVocabs` package attribute to compose a special vocabulary tree if necessary.
You can refer to the generated tree of vocabulary roots via the newly exposed `vocabTree` attribute, as described in the [documentation](#ssec-factor-dev-env).
- Nixpkgs configuration, specified for NixOS using `nixpkgs.config`, or using the `config` argument when importing nixpkgs, has learned to accept a `lib` argument as well as `pkgs`, which allows the configuration to be computed without depending on the `pkgs` fixed point. If you are referencing licenses in `lib.licenses` by having this configuration be a function taking a `pkgs` arg, you may wish to change to using `lib` for faster computation and to avoid infinite recursion errors if pkgs depends on parts of the computed configuration in future.
For example, if you currently have configuration that looks like this: