Lesson learned with package.json

Posted October 2nd, 2012 by guidone with No Comments

I’ve been using NodeJS for a project of mine and I was used to setup my package.json in this way:

...
   "some_external_lib": ">= 1.0.0",
   "another_external_lib": ">= 1.4.0"
...

I thought: the newer a library is, the better.
And I was wrong. In this way there’s no control on what is going to production/staging servers, if a new version of some_external_lib becomes available, let’s say 1.5.0-i-am-very-alhpa, that unstable code will be deployed on production.

Since the local environment is no longer aligned with production/staging (even if we cast a npm install locally), any bug introduced by unstable code will be very hard to spot in the local environment (likely you’ll end up debugging on production server).

Lesson learned: eradicate any “>=” from your package.json.

Middleware in NodeJS

Posted March 16th, 2012 by guidone with No Comments

Talking with a collegue of mine I came up with this solution about organizing the code in NodeJS+Express using middlewares.
Consider this example in which we have a simple page that performs two queries and shows the result in a template.
Since everything is asynchronous, we chain in two queries in this way

app.get('/mypage',function(req,res,next) {
   sequelize.search(query1)
      .on('success',function(res_query1) {
         sequelize.search(query2)
            .on('success',function(res_query2) {
               res.render('my_template',{
                  query1: res_query1,
                  query2: res_query2
                  };
               });
         }
   });

There’s nothing wrong with this, the only problem is that as long as the page gets new functionalities, you keep nesting queries and asyncronous callback.
The resulting code could become unreadable after few cycle of releases.
Continue Reading

A Javascript manager and build tool

Posted January 31st, 2012 by guidone with No Comments

I was playing around with Jake last days and I came up with an idea for a tool to create a piece of code to handle seamlessly the the various JavaScript libraries in a HTML page with NodeJS and the check/compress/build procedure to release the whole package in production.

I’m still working on the idea, probably it will end up in something with a little bit of conventions for the structure of the files, but these are the key points I really need for this tool:

  • Be able to work with AMD modules and simple JavaScript files at the same time (without converting them to AMD module format)
  • Full support to AMD and module dependencies
  • A unique file to define which JS files and modules to load for each page, used to render the page and build the release package for production (no more manually updating of the build script)
  • Paths mapping for easily switch JavaScript library version (or to point the static resource to a CDN)
  • Check the files against JSHint before building (damn comma in array!)
  • Categories

  • Tags

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2 other subscribers

  • Twitter

    Flickr Stream