> The best NPM packages are small and focused
100% agree.
> having lots of internal dependencies is probably a smell.
Less agree.
Having lots of internal dependencies is normal for things that are
doing complicated things. However, it's ideal for them to take a
relatively small number of things, and turn it into one thing. Then
you'll tend to end up with lots of meta-deps, but still a small number
of 1st-order deps.
Module dependency trees ought to be bushy - ie, not a narrow deep
tree, and not a flat long tree. Then, you cna use `npm dedupe` to
remove duplicates, and simplify things before checking into git and/or
deploying.
> There is really no functional difference between using this vs relative
> requires, it's psychological. It makes me focus on keeping lib pure, and the
> lack of ../ gives me the warm fuzzies.
This is so very telling! Thank you for this fascinating bit of
insight. You captured it so perfectly.
I'd argue that your "warm fuzzies" reaction is 100% valid: a lot of
../ in your require paths tends to indicate some inappropriate
intimacy and merging of concerns. However, you haven't actually
solved the problem! You've only removed the surface manifestation, to
make it *look* like you're using nicely abstracted components. But
those components are not, in fact, nicely abstracted. They're still
doing a ../ require into a bag-o-stuff lib folder, but just without
the ".." in the string.
Why not just put your "emerging utility stuff" in
node_modules/some-util/ and node_modules/some-other-util/, and do
require('some-util') in your app code? List each util as a
"bundledDependency", and check it into git. If you ever decide to
split it out, it's super trivial to do so.
This way, you'll notice right away if you have too much cross-talk
between them. Because, if "util-a" is pulling in "util-b", but
doesn't list "util-b" as a dependency, then that's an easily spotted
error. If it DOES list util-b as a dependency, you'll force yourself
to think, "Wait a second... why does it *actually* have to depend on
that other thing?", and then wonder if they should be merged (ie, if
they are tightly bound, and probably not a good abstraction
independently), or more fully separated. The smells will be right in
your face, instead of hidden behind a magic folder.
Over the last year, I've been retroactively doing this with npm, or at
least, trying to find time to do so, and since things are already
working, it's hard to justify the time expenditures. I really wish
I'd built it this way from the start and a lot of annoying mistakes
could have been avoided. Of course, to be fair, at the start, there
was no npm to make this sort of thing easier to do :), but my point is
that it's sooo much easier to do up front rather than trying to do it
later on, once you have a tangled mess.
On Sat, Feb 9, 2013 at 12:02 PM, Jacob Groundwater <[email protected]> wrote:
> There is definitely a method to my madness.
>
> First, I would only recommend doing this in a deployable application, not a
> module that deploys to NPM. The best NPM packages are small and focused;
> having lots of internal dependencies is probably a smell.
>
> Second, I do this to help filter out code that belongs in a library anyways.
> I have two directories at the root of my project which separate code
> functionality.
>
> /app <-- contains MVC architecture of web application
> /lib <-- contains emerging utility libraries
>
>
> Note that nothing in /lib should directly require anything in /app. The
> libraries in lib should evolve into separate, and self-contained modules.
> These are the future candidates for NPM modules.
>
> Since modules in lib should behave like external libraries, I require them
> like external libraries. I symlink lib into node_modules.
>
> /node_module
> /lib --> ../lib
>
>
> In your application, you can require any of these modules with
>
> var module = require('lib/module');
>
>
> When time comes to actually refactor these modules into their own code, it
> is a relatively straight forward to change your application.
>
> Under this model, I was able to hunt down all my upward requires and help
> eliminate some bad design in the process.
>
> There is really no functional difference between using this vs relative
> requires, it's psychological. It makes me focus on keeping lib pure, and the
> lack of ../ gives me the warm fuzzies.
>
> Finally, if your only reason is to avoid typing two periods, I would
> question your whole approach. Fewer keystrokes do not make a better
> application.
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
