Isn't that the whole reason there is a package.json? That way, people just run npm install and already have all the necessary dependencies.
Here's some discussion on a related idea:
https://github.com/rails/rails/commit/2dfff4d31634d669f4c198...
In that case, the "offered" dependency was on the mysql2 gem. The intent was similar (don't want to force users of ActiveRecord to install DB adapters they don't use) but ran into an unexpected situation when the generated Gemfile entry didn't have a version constraint but the runtime-loading code did.
Honestly, this sounds like a big step backwards in UX if implemented widely.
I would really rather not have to manually install a million packages when pulling down dependencies - "npm install && npm start" and then going to grab a glass of water feels great.
The given use case of a master parsing library doesn't really resonate. A handful of extra kb on disk doesn't bother me at all for an all-in-one solution, and I've never really had the problem of not being able to find a parsing library on npm to begin with.
He said that approach "d" (implement every implementation) has the problem that "It will take a lot of time to implement all configuration files properly".
Somehow that problem disappears when using his approach, and I think that's even bigger problem than the download size of the dependencies.
I'm not shure that it is a good idea to create (and use) such packages as 'parse-any-structed-file'. If you know what you need, then you can use an optimized implementation.
Correct me if I'm wrong, but this would mean that I will be informed about missing dependencies RUNTIME? And I have to do that multiple times, if there are multiple 'dynamic dependencies' like this. The main reason for having declarative dependencies is to NOT be having to do that.