First thoughts on using node2nix to mange a development environment which contains a mix of Python and Node dependencies. In this step I describe my use case and the first impressions of node2nix.
My current main use case
I am using the node based dependencies to build the frontend assets. Mostly the build is based on Webpack in my new projects, and on Grunt in my older projects. In a typical project of mine, there are also Python assets involved.
The node dependencies are used then only to build my projects, they are not needed at runtime.
Grunt poses a special requirement, since it enforces to be installed locally. So far it is easy to trick it into accepting my setup by creating the folder node_modules and symlinking the needed grunt parts. That's not very elegant, but does the trick.
The node dependencies are then available when running nix-shell, so that developers automatically get the right dependencies.
The same set of dependencies is used for the build, e.g. via nix-build.
npm2nix vs node2nix
Not going into any details, the main difference from my perspective is how the dependencies are placed inside of the store.
- npm2nix places them individually and then tries to symlink things together, which can result in a deeply nested structure.
- node2nix places the sources individually into the store, but then installs them all into one environment. This way it can be closer to the way how npm itself would work.
A very good explanation of all details behind node2nix is available in a blog post from Sander van der Burg.
Need from a developer's perspective
Looking from my use case to mainly provide a development environment, both tools should get the job done. For this particular case I see the level of convenience for the developers who work inside of the provided environment the most critical aspect.
Number one factor is how easy is the day-to-day usage. In the ideal case it should be sufficient to run nix-shell and start hacking. I consider this the most important aspect, since it scales with the number of involved developers. Especially in a bigger team this has the potential to save time. Or writing it in the negative way: If I accept to loose time here, this time will always have to be multiplied with the number of developers who use the environment.
The second important aspect for my use case is the regular maintenance of the environment. This is only priority number two, since this does not affect all involved developers. My assumption is, that we can accept a little bit more work for maintaining the environment, if we save more due to the day-to-day usage and it's scaling implications.
It is important though, that a developer can add a dependency into the environment without too much efforts.
First observations and experiments
The main reason why I started to look into node2nix is that I was starting to struggle with the time it took to enter a npm2nix based environment for the first time.
In a project which uses ReactJS, Redux, Babel, Webpack and a bit of Grunt, I ended up with a massive amount of dependencies to get the environment bootstrapped. Apart from that I started to observe issues due to peer dependencies which made maintaining the dependencies more tricky.
As a first experiment I used node2nix to just generate the Nix files and tried to enter nix-shell. Two observations:
- Building the environment was quite fast. Each change will need a full re-build of the environment though.
- Re-entering nix-shell was very fast. I have to admit though, that I did not yet notice this as a problem in the npm2nix case.
- It seems that the generated environment is smaller, especially when using the parameter --flatten. This is just a first impression though and might be misleading, since I did not yet fully integrate the node2nix generated environment.
- Integrate the node2nix generated environment fully. This will result in an environment which is comparable to my current npm2nix based setup.
- Test out maintaining the node dependencies, e.g. addind, removing an updating of dependencies. This should ideally be doable even without too deep Nix knowledge.