Never mind, I think I figured it out. In NPM I think all the modules you
need are themselves visible to the public npm repository, which does
simplify everything as ryanos points out. However, putting closed source
code in the public npm repository, even marked as private, makes us pretty
nervous. We will probably check in some sort of stub redirector as Martin
suggests in his second post, which acts like a symlink but works on
windows.
I think we could also split our utils out into separate private git
repositories and pull them in with giturl dependencies, but at the moment
that seems a little heavyweight. If npm supported file system paths as
dependencies I think we'd be super happy. Just feature request. We can
make the current system work.
-g
On Tuesday, February 12, 2013 10:43:41 AM UTC-8, George Snelling wrote:
>
> 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 <[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.
