it's 317 unique crates, some of which are internal

  305 with helix- removed
  258 with gix removed (git stuff in multiple packages from a single upstream group)
  240 with windows api wrappers removed.
  170 if you remove all subprojects (split on -/_ taking first field, then uniq).

what's left?

  fast math and various hashes
  backtrace utils
  various build utils
  some allocators, zero copy facilities, mmap and structures   like lrus
  time and date handling
  character maps / internationalization
  concurrency libraries (futures, runtime, etc)
  cross platform path & directory helpers
  support for general unix platforms, for redox, for linux, for windows
  logging infrastructure
  some compression libraries
  markdown
  various testing helpers
  rope string representation
  shell lexer and utils
  terminal interaction models
  toml
  wasm & wasi

compared to neovim, which is hard to determine because c & cmake toolchains are a bit of a shitshow to figure out, but lets take a look at maybe debian, that says 34 package dependencies downstream. The list is clearly missing a bunch of the toolchain, has limited portability and so on, but certainly shorter at 34 - for a single platform. Note also that neovim bundles several dependencies (e.g. markdown and so on - so they're "hidden" (almost surprising debian hasn't done their usual trick of insisting this isn't hidden))

so where's the rest? well the rest is in the project: tokei says helix contains 132kloc. tokei says neovim contains 984kloc.

so round a little and you get: helix has an order of magnitude more dependencies, but also an order of magnitude less code than neovim.

while I'm sympathetic to concerns around dependency bloat, particularly with an eye to the js ecosystem and supply chain security, it's important to look through the right lens - when the functionality is fairly closely equivalent (there are differences, helix has a lot more modern features, vim has a lot more traditional text manipulation and unixy integration features), and there's an order of magnitude tradeoff in both directions - this is likely demonstration of fairly effective code sharing in helix.

there are important supply chain safety techniques required when using a wide number of disparately owned dependencies. there are also important supply chain safety techniques required when managing a wide number of disparately owned sub-directories of a larger project. there could just as well be a needle in neovims vimscript haystack as there is in helix dependency stack, i can tell you now though, as i'm familiar with almost all of helix dependencies i've put eyes over their code at least once, there's almost certainly been more eyes on helix deps recently than on neovims vimscript - though eye's passing over don't always catch things either of course.