Over here on Project IDX, we like to work fast. A big part of that means making sure we’re building the tools we need to increase efficiency and streamline the grunt work that hampers our velocity. As developers coding in a browser-based workspace, one of the pain points we felt keenly was the startup cost of setting up a new workspace with all the dependencies we needed, and the environment configuration we wanted. So, one of our priorities in building IDX was to address that pain point with streamlined workspace configuration — which we did by building Nix into IDX.
How does Nix fit into IDX?
IDX uses Nix to define the environment configuration for each workspace. Nix is a purely functional package manager that assigns unique identifiers to each dependency, which ultimately means your environment can contain multiple versions of the same dependency, seamlessly. However, for us, the extensibility, programmatic configuration and effective environment caching we get from Nix provides the biggest payoff.
Nix is also reproducible and declarative. In the context of IDX, this means you can share your Nix configuration file across workspaces to load the same environment configuration. IDX defines the preview environment and workspace package configurations directly in the code repository with the .idx/dev.nix file. So, if you want to jumpstart your pair programming, you can share your Nix configuration file as part of your code repo and your teammates can dive right in with minimal setup. This is also a cornerstone of how we build templates for a wide variety of frameworks and languages in IDX.
If you’re familiar with Nix, however, you might notice that our implementation doesn’t follow a strictly traditional Nix model. We built Nix into IDX workspaces as a way to manage packages and configure VM environments attached to them, not as a pure, complete NixOS installation.
Why did we choose Nix?
We wanted IDX workspaces to work for any developer, anywhere. Part of our philosophy is to avoid proprietary tools, languages, or configuration models wherever we can. Beyond that, we want to contribute to the developer community whenever possible. Nix is widely available and community supported, so it made sense to build it into IDX as our configuration model.
In addition to the IDX-specific attributes and packages to define the preview environment in your browser-based workspace, you can depend on any packages that are available on Nix. We wanted to support a tool that most of our engineers could use, and that could support the tools our developer users want.
For example, using Nix allowed us to add instant tooling to IDX. When you want to use a tool from the command line, all you have to do is run its command. If it's not already installed in your environment, the terminal shows a prompt with available Nix packages exposing a command with that name. If you choose one, IDX then grabs the package behind the scenes and executes the command. Easy peasy.
How do you use Nix on IDX?
When you create a new workspace, a .idx folder with a dev.nix file is automagically added to your root directory. (If it isn’t, you can create it yourself to enable Nix.) You can define packages and your preview environment configuration here, following the Nix attribute set syntax. You can see a list of IDX-specific packages and a detailed sample in the IDX technical documentation.
What’s next for Nix on IDX?
We firmly believe that the sky’s the limit for flexibility and extensibility in IDX workspaces, and we’re working hard to boost productivity for our developers — and ourselves — as much as possible. We recently also made it easier to edit dev.nix files thanks to syntax highlighting, auto-completion and error detection.
Beyond that, we’re hoping to add even more templates to make startup and setup even easier and faster for common workspace setups. Because, as we might’ve mentioned once or twice, we here at Project IDX like to work fast.