Change:
<del> # This file has been generated by node2nix 1.5.3. Do not edit! {pkgs ? import <nixpkgs> { inherit system; }, system ? builtins.currentSystem, nodejs ? pkgs."nodejs-6_x"}: let nodeEnv = import ../../../development/node-packages/node-env.nix { inherit (pkgs) stdenv python2 utillinux runCommand writeTextFile; inherit nodejs; libtool = if pkgs.stdenv.isDarwin then pkgs.darwin.cctools else null; }; in import ./node-packages.nix { inherit (pkgs) fetchurl fetchgit; inherit nodeEnv; } </del>  No newline at end of file

Discussion:
zed uses the binary release of (at this time still called ), while the newest version is . As this is basically a Chromium binary that can execute arbitrary Javascript and deliberately breaks all sandboxing features, we should at least keep it on a current version. cc I’m pushing an update of to 0.26 at the moment, but the package can’t handle it, so I’m pinning to for the time being.
Hi Thanks a lot for working on this. It's been a while ago since I worked on this part of , but I slightly remember that I had to deal with several outdated versions when dealing with . I'll definitely have a look into this in the next days, hopefully there's a patch by some contributors (or it's easy to file one to fix this). However the project isn't too active, so at least when we suffer from more further breaks or security issues because of severely outdated dependencies, we shouldn't hesitate to mark this package as broken or even drop it entirely (unless there are folks heavily relying on this).
I’d be in favor of a drop; people will complain if they still use it, if that happens we can restore & update, or the package is pulled outside of nixpkgs until someone can push and maintain a recent update.
In fact I agree with you, I've observed this "restore & update" pattern with some bigger applications (especially web-services) and I think that this is unneeded extra-work for the nixpkgs maintainers and release managers before each release. Before I file a patch to either {drop it,mark it as broken} or fix the dependency issue, I'd like to check two things before: is there any active fork? I'd like to ensure that the project is actually dead/unresponsive or does it have a working/maintained fork? check in the IRC if there are active users (I don't use it, I just fixed the derivation to help to get rid of ). If there are any, we should ask them to take over maintenance (or ask them to create their own overlay) I'll try to have a deeper look into it tonight, when I know more and have an actual opinion on how to proceed, I'll leave a comment here.

As far as I know, the author is no longer actively developing Zed anymore: I happen to know him personally, but as far as I know he has no interests in doing any major additional developments any time soon. Of course, I can always ask but I think I already know the answer. :) For me it's fine if it gets removed.
ok I suspected something like this as the last commit was from 2015. In this case I'm also :+1: for dropping it...
just submitted a PR for now, I asked in the IRC if there are any folks using , if I don't get a response, I'd just vote for merging it to master and do a backport to 18.03