Isaac,
We have this issue too. We thought symlinks in node_modules would work,
but we've got some windows folks, so no luck there. I was looking at npm,
and as far as i can tell, it looks like your pattern is to check most of
node_modules into git, and then pull in almost all modules, yours and
third-parties, using
"repository": {
"type": "git",
"url": "git://github.com/TooTallNate/node-gyp.git"
},
in hand-edited package.json files. Is that right? We are not used to
checking in node_modules, but I'm willing to try out your pattern.
However, I'm confused about the relationship between the package.json
files checked into node_modules, vs the package.json files at the root of
the modules in their home repros, for example:
https://github.com/isaacs/npm/blob/master/node_modules/node-gyp/package.json
vs
https://github.com/TooTallNate/node-gyp/blob/master/package.json
How are the dependencies kept in sync between the two if Nate changes his?
Sorry if this is obvious...
Thanks,
-George
On Saturday, February 9, 2013 6:17:09 PM UTC-8, Isaac Schlueter wrote:
>
> > 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
> <ja...@nodefly.com<javascript:>>
> 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 nod...@googlegroups.com<javascript:>
> > To unsubscribe from this group, send email to
> > nodejs+un...@googlegroups.com <javascript:>
> > 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 nodejs+un...@googlegroups.com <javascript:>.
> > 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 nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
