kind of off-topic but I used to hate to "calculate" relative paths when doing require, so what i did is to build an extension for my code editor that let me search files by name or folder name, and when I select it it auto calculate the relative path from the file i am editing and insert the right require clause.
It also let me select node native modules (fs, events, http, etc) and modules i have installed on my node_modules folder. This stupid thing really help me a lot on my daily job and saves me a ton of time. https://github.com/jfromaniello/sublime-node-require There is an out-dated gif there demostrating how it works (or used to work). If you are on an empty line it will insert something like: var x = require('./x/foo'); if you are on non-empty file it will do just the require call: require('./x/foo') 2013/2/9 Isaac Schlueter <[email protected]> > > 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. > > > -- -- 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.
