you can put a tar-ball as dependency too, this is what we do with our
private packages.
another approach is to npm link the packages locally
Am Dienstag, 12. Februar 2013 20:21:14 UTC+1 schrieb George Snelling:
>
> 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.
