"Instead of including modules by complicated pathing like require('../../../shared/utils'), it’s much simpler to require('utils'). Utils can be symlinked from another folder in the source tree so that you can continue to actively develop it and the changes will be reflected in the dependent modules."
This sounds like a maintenance nightmare when you start juggling lots of code.
This is definitely a fair point. So far, we've found it to work well by keeping our packages fairly well organized.
A simpler solution might be to put your custom modules in node_modules (without symlinking) and then commit those to your source tree.
The main point that I wanted to get across was that it's worth structuring your packages in such a way that makes it easy for developers to write new modules without using a lot of relative paths in the file system. Node does this work already, so I like to take advantage of it.
Not really. You just develop independent, reusable modules, drop a package.json in the module and npm link the module to your app. It gets symlinked to your app's node_modules.
Also important to not fall down the hole in a couple of years where these shared libraries are being used all over the place and changing them becomes hard. Good to always question if they should be a module or perhaps their own api.
Agreed re: shared libraries being used all over the place, but I don't think that requires changing a module to an API.
git submodules are designed to solve this problem and do so very well, allowing each project that uses a shared module to include whatever version it pleases, yet allowing the project using the shared module to update/rollback to a newer/older version.
You might be trolling, but custom $NODE_PATH configurations are a slippery slope and can reintroduce dependency hell f you're not careful. You're voluntarily disabling one of npm's finest features. This sentiment is even in the manual:
"[$NODE PATH exists] mostly for historic reasons. You are highly encouraged to place your dependencies locally in node_modules folders. They will be loaded faster, and more reliably."
I actually use $NODE_PATH, mostly for historical reasons. It would certainly get unwieldy if you added more than one directory to it. It's nice to have a place for small shared library files that don't justify their own package.json, but as things get more mature they end up in node_modules.
May be a valid use case so long as you know what you're doing, and if this works for you, that's great. Though, considering the fact it's generally a bad idea, advising people to break the rules should probably be qualified with a serious disclaimer when presented in the comments of a post appealing to beginners...
> ...small shared library files that don't justify their own package.json...
Generating a package.json + dependencies is a 30 second job with npm init + npm install --save + npm link. I follow a similar pattern to you when developing inside a single module, where I start growing module saplings in a ./lib folder to spike on ideas without the overhead of totally decoupling from the parent, but as soon as you need to share that code around and put it into your $NODE_PATH, you've got to decouple it anyway, so really you're effectively 30 seconds worth of work away from creating a real module anyway, and thus you could do away with your custom $NODE_PATH.
I am sure you are a most upstanding, interesting, and funny fellow. I respect that you appear to possess a love of hats.
Despite my sincerest regards for your person and well being, I must say that the UI of your site is somewhat hard to use. I, and others like me, read the web as much from our small screen devices as we do from our big screens.
Your site, when viewed on an iPhone, has a large overlay at the bottom containing a photo of you wearing a hat and your name, and it takes up nearly 1/3 of the entire viewable screen. It makes reading the content of your site uncomfortable, and nigh impossible. This is at least the 2nd article from your site which I have had to avoid from Hacker News. This is disappointing, since having made the homepage several times indicates you are someone I might find interesting. As it stands, I am bereft of being able to discovering your thoughts and reflecting on them myself.
Please, consider a modification to your UI for those of us who only have small viewports with which to interact with the world.
Designer here. Good point about mobile styles! I got frustrated with the media queries and stopped short of fixing em, but as soon as Calvin pulls now he should have a more lenient header on small screens.
I would also recommend everyone to check out express-on-railway https://github.com/1602/express-on-railway a rails like mvc framework for node with intuitive design to be adaptable for sockets.
Nice! 'async' is almost essential for me: the 'waterfall' style in particular. I modularize everything too, but using AMD modules.
- I move between client and server fairly frequently, and AMD works in both via RequireJS.
- I often share code between client and server, eg, my current app has a shared models module that is augmented by the client and server-specific modules that import it.
I avoid adding methods by a string for the simple fact that JSHint warns about using [] rather than . wherever it can (I think the only time I use [] is for Express' badly named 'static' plugin - 'static' is a reserved word.
Following you on Twitter (I'm @mikemaccana). Hope to catch you about someday!
Thanks! I haven't been using AMD so much since I've mainly been working on the server-side js, but it seems like a similar structure.
The shared code between client and server is definitely an interesting concept. I'd be interested to see some of your posts on how this ends up working!
Express-resource is cool - I haven't gotten the chance to use it in a project yet so I can't comment too much on it.
Our app isn't grouped strictly into resources, though it's something we might be able to benefit from. Currently we use different pieces of middleware to load whatever items the route needs.
This sounds like a maintenance nightmare when you start juggling lots of code.