I wanted to say thanks for the detailed post.

I was able to make some progress on packaging the project. A few issues I faced:

• node2nix was not including devDependencies by default. It’s possible with the -d flag, but that would include all devDependencies into the final build, and I could not find a way to remove that for production build.
• I tried skipping node2nix, and simply included package-lock.json file, this worked, but there were more difficulties
• Machines (the plugin) requires source repository of the cockpit-project. I first tried building the plugin from the cockpit-project package, but that did not seem very clean. I then created a separate package like you suggested, and listed 2 project sources, that seemed a bit cleaner, and now that package can be included from cockpit-project package, avoiding circular dependency.
• This all worked! Great! I had modified the cockpit-project package to include the plugin, and was able to have the package successfully (or so…) and copy it over so it’s found.
• And yet, there does not seem to be clear compatibility matrix between the cockpit-project, and the plugins. Makefile for the machines plugin simply includes the commit hash of the parent project, and includes its libraries in the build process.
• Unfortunately, the build did not result in the working plugin, and this is where my expertise in troubleshooting node applications comes to a limit.

Despite the failure of the outcome (I don’t think I am willing to invest more time into this build right now) I learned a ton about building nix derivations, packaging software, and various troubleshooting tips.

I was able to hack on a project really successfully, using nix repl. However, to test that on my system, I had to fork nixpkgs, include that in my flakes, and rebuild the system. I would like to find a more isolated, easier way to test my packages, without affecting my main system.