
Node.js: Be a good dev: offer dependencies - leichtgewicht
https://medium.com/@leichtgewicht/good-dev-offers-dependency-234ce6e1fbf2#.vsvkg2nu6
======
sevcsik
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.

~~~
leichtgewicht
Yes, the missing dependencies would show up at runtime. Which is a valid and
important concern, however: It would be possible (though probably inadvisable)
to implement an automatic download of missing dependencies.

~~~
dozzie
Which is as terrible idea. You have some code deployed, and suddenly this code
downloads random things from internets without any control whatsoever.

Even worse if the application was deployed behind firewall and can't access
internet freely.

~~~
leichtgewicht
It is definitely a bad idea when working on a server, but for a cli tool or
some editor that might install it anyways it could be arguably worth a try.

~~~
dozzie
It's JavaScript. If you make any thing that's merely silly in command line
tools, it will end up being adopted where it's a terribly stupid idea.

Plugins are plugins and dependencies are dependencies. Don't mix them up.

------
arik-so
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.

~~~
leichtgewicht
Yes, a package.json is good to get the _required_ dependencies. This article
is about possible dependencies that help in cases where you all the possible
would mean a huge load on the system.

~~~
flukus
If you can use a package without them then they aren't really dependencies are
they?

~~~
leichtgewicht
True, how should those things be called?

~~~
myhf
A good example is Consolidate, which provides a consistent API to various
template libraries. You wouldn't want to force installation of all the unused
libraries.

[https://github.com/tj/consolidate.js](https://github.com/tj/consolidate.js)

~~~
leichtgewicht
Will add a link to the "other problems" list, thanks!

------
al2o3cr
Here's some discussion on a related idea:

[https://github.com/rails/rails/commit/2dfff4d31634d669f4c198...](https://github.com/rails/rails/commit/2dfff4d31634d669f4c198c4fb85b59d39477862#comments)

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_.

------
easong
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.

~~~
leichtgewicht
You do have to choose which packages you want to install at some point. When
you do `npm install && npm start` it will still work as planned. The problem
here address is for when you need to deal with a new issue.

If it were a handful of extra kb, I'd agree. Of the top off my head I can
think of following file formats "somehow" suited for configuration: json,
cson, properties files (java), yaml, xml, conf-files (Apache), ignorefile
syntax, ini files.

Supporting all of them could be a reasonable goal to the community (looking at
the packages in npm: it is an actual goal already).

[https://en.wikipedia.org/wiki/Configuration_file](https://en.wikipedia.org/wiki/Configuration_file)

~~~
nailer
Use js files for config. They support comments, syntax highlighting will work
out of the box, and you can require them.

~~~
leichtgewicht
A problem that I have with my article is that readers seem to get hung up on
the config loading bits when I tried to use it as an example for a more-
general problem.

To fix this I added a section to the article:
[https://t.co/sXJhTYXQvy](https://t.co/sXJhTYXQvy)

(Using executable files for configuration can be an enormous problem for some
uses.)

~~~
nailer
I think it's a poor example. I don't want to choose between 20 different
config file formats. Give me a config file in a format I know.

------
joesb
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.

------
vsenko
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.

~~~
leichtgewicht
In my use-case I would like to offer as many structured files formats as
possible. But to be sure: you can replace "structured file" with "code syntax"
(example: syntax highlighting) or "natural language translation" (example:
translation of a cli tool) or "database driver" (example: orm tool).

(In my project that is the exact problem case)

