Question

I’m working on my first Cloud Foundry project (…and first Node.js project, and first MongoDB project, and first “express” project, etc. etc…)

On day one I found this question, and used the answer as a jumping off point for the organization of my github repository:

Folder structure for a Node.js project

There is a /node_modules directory which is not checked in. Rather it is created automatically by npm install based on the specification in a package.json file. Okay, good…I made that file.

(Note: During a vmc push, it seems there is no examination of the package.json file by the pushed-to server. It seems to merely copy over the node_modules directory and does nothing if it doesn’t exist…so it’s necessary to do the npm install on your client and THEN push.)

I’ve got some basics working in my application, and am now at the point where I’d like to begin laying down testing and building infrastructure. For instance: I’d like a build process that will run linting on all my JavaScript. There’s a continuous integration library called ready.js that looks like an up-to-date build tool…

But something feels wrong about being in my project’s directory and doing npm install ready.js. This means that more stuff will be going into the /node_modules directory and uploaded to the cloud, when it’s not intended to run on the cloud. By the same token: if I have a build process that’s doing minification of resources (or whatever) then I don’t want the source being deployed with vmc push either.

I know all this is new…but is there a convention to dump the targets into a build directory and push from there? Or does everyone push from what is effectively the github root, and just push all the builds and tests along as well? Any tips are welcome…methods to use, methods to avoid…

UPDATE: I found an application boilerplate for using express and Node.js (as well as several other common modules), which does its “build process” inside the server code’s javascript…for better or worse:

https://github.com/mape/node-express-boilerplate

I also found this, and it seems like combining the term “boilerplate” with names of modules you’d like to see incorporated into the structure is a good search strategy for finding the sort of thing I am looking for:

https://github.com/swbiggart/node-express-requirejs-backbone

Answer 1

npm allows you to specify devDependencies, you may want to see this article.

You could add all of your dev/test environment dependencies under devDependencies and all production-related modules under dependencies. Then, you could add a script to push to the cloud.

I’m not familiar with Cloud Foundry or the vmc push workflow. But, you could add a custom script to the scripts object in package.json which installs dev-environment modules, runs your tests, cleans the npm cache, then installs production-only modules and pushes your code and only those modules to the cloud.

edit

I’m not sure you can use these if not pushing to the npm repository, but they are useful as an example (I guess…) Alternatively, you could automate the workflow I described above in a shell script or node script.

/edit

You could hook into any of the scripts available… (see man npm-scripts for more info):

   preinstall
          Run BEFORE the package is installed

   install, postinstall
          Run AFTER the package is installed.

   preuninstall, uninstall
          Run BEFORE the package is uninstalled.

   postuninstall
          Run AFTER the package is uninstalled.

   preupdate
          Run BEFORE the package is updated with the update command.

   update, postupdate
          Run AFTER the package is updated with the update command.

   prepublish
          Run BEFORE the package is published.

   publish, postpublish
          Run AFTER the package is published.

   pretest, test, posttest
          Run by the npm test command.

   prestop, stop, poststop
          Run by the npm stop command.

   prestart, start, poststart
          Run by the npm start command.

   prerestart, restart, postrestart
          Run by the npm restart command. Note: npm restart will  run  the
          stop and start scripts if no restart script is provided.

   Additionally,  arbitrary  scrips  can  be  run  by doing npm run-script
   <stage> <pkg>.

Note, publish here is for publishing a module to npm. You should set your package to private ("private": true) so you don’t accidentally publish your code the the npm repository.