5

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

Community
  • 1
  • 1

1 Answers1

3

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.

Joseph Yaduvanshi
  • 20,241
  • 5
  • 61
  • 69
  • see [jade\package.json](https://github.com/visionmedia/jade/blob/master/package.json) for an example of how it all fits together. – Joseph Yaduvanshi Apr 19 '12 at 18:28
  • Interesting stuff to know, and all new to me--thanks! It would take care of one axis of the problem as pertaining to node_modules...although it sort of seems one would wind up pushing from a special alternative `npm install --production` directory. The issue of having superfluous "source files" in subdirectories that CloudFoundry just picks up would remain though, so I'm hoping there are some CloudFoundry idioms to pick up here as well... – HostileFork says dont trust SE Apr 19 '12 at 18:52
  • Update...I found this "ready.js" and it seems to be along the lines of what I'm looking for, at least it's being currently maintained. I'm still not sure how to lay out the workflow...if npm scripts should be involved, or if I should write straight JavaScript "makefiles" to make a `/build` directory that I actually wind up "pushing": https://github.com/dsimard/ready.js – HostileFork says dont trust SE Apr 21 '12 at 15:03
  • 1
    I looked at ready.js, and it seems to be geared toward writing consistent code and minifying the code. I also looked at [cloudfoundry/vmc](https://github.com/cloudfoundry/vmc) on github briefly, and I didn't see a way to specify files or modules included in the deployed application. I use heroku for my node.js applications which makes deployment easy... I add files/folders to `.gitignore` and they don't get pushed. I did stumble across [this video](http://www.infoq.com/presentations/Code2Cloud) which discusses Code2Cloud and CI/deployment to Cloud Foundry. – Joseph Yaduvanshi Apr 21 '12 at 17:04
  • Looking at the code, always a win. :) Well then if you've looked at vmc and there's no way to subset what gets pushed then it sounds like pushing from a "build" directory is the way to go...do you have any personal best practice for what scripting/building methods I might use to fill up that build directory from disparate resources in the repository? :-/ – HostileFork says dont trust SE Apr 21 '12 at 17:46
  • If it was me, I'd use a makefile. In my clone of Mastering Node, to push current changes to gh-pages, I checkout the `gh-pages` repository into a subdirectory, move all relevant changes into the subdirectory, then spit out a message to manually verify and push to `gh-pages` [See the Makefile](https://github.com/jimschubert/masteringnode/blob/master/Makefile#L71). You could mix [git archive](http://stackoverflow.com/a/163769/151445) and the `devDependencies` to test, archive to `\build`, `npm install --production`, then push. – Joseph Yaduvanshi Apr 21 '12 at 18:01
  • Hey, I've added some links to the question. It seems that the term "boilerplate" is strongly Googleable when one is curious about this. I'm trying to figure out just how viable it is to fork boilerplate git projects/subprojects so that I can inherit downstream changes... though this puts *more* pressure on the build process to integrate files from git-tracked locations to where they need to be. Thanks for the help...I'll push on this and maybe fall back on old-school things like makefiles. Comments welcome: https://github.com/hostilefork/blackhighlighter – HostileFork says dont trust SE May 08 '12 at 14:31
  • I'll have to check out your project later. I'm interested in seeing how it comes together. As far as boilerplates, some people love them and some people hate them. I've tried to use the express boilerplate and ended up removing all of the boilerplate code because it wasn't useful to my situation. – Joseph Yaduvanshi May 08 '12 at 16:08