plans for new features?

[panosru]

Hi, I'm wondering if you have plans to add more features on this project, I saw assets manager and assets manager handlers and it have some neat features inside it (mostly I love the vendors replacement handler and the minification of css and js files). Both assetsmanager and assetsmanager-handlers are not working and I prefer the way bundle-up handlers assets by generating files, bundle them and provide methods to the view engine.

Thanks

[Cowboy-coder]

I don't have any specific plans for new features except for minification of Javascript. Currently CSS is already minified by default when bundle:true is set. The reason I haven't implemented minification of javascript is because I haven't had any personal needs for it yet (and it's really annoying with breaking minified javascript, so personally I think it's a little gain for a lot of pain).

Regarding the vendors-replacement technique I do like it. I'm thinking about adding some kind of plugin functionality, so that people easily can add custom things like vendors-replacement, base64 url replacement in css etc.

But if you're using stylus together with nib http://visionmedia.github.com/nib/ (which you should :) you don't need to think about vendors-replacement, since it's already baked in that all css3 stuffs generates vendor-specific styles.

[panosru]

Wow! Thanks for the info on nib! I didn't knew about it, as I said I'm doing R&D on node since two weeks now and I have to admit that I love it so far (I wish JavaScript was more powerful from OOP perspective but that's a big discussion!)

Yes I noticed that css files are minified when they are bundled but I have to disagree on "little gain for a lot of pain", having javascript minified is not a little gain, personally I believe is little pain for a lot of gain since from performance perspective you gain a lot.

From development perspective indeed there are times when minification screws things up underneath making the developer scratch his head for some time but still I haven't faced that situation often, usually when shit happens you know when the stink comes from :P

Yes adding plugin functionality would be great I don't want to alter vendor's code but when they don't give em a way to 'hook' some functionality I end up having to do it...

[Cowboy-coder]

Yeah, true. Plugin or "hooks" (is actually a better name) is important because you are pretty much screwed without it if you want to customize the output. I will add it as a feature ticket. I just need to come up with a good api. The problem is that every hooks needs to be synchronous because it needs to be done during app-startup when bundle:true is set. This is because the whole build process needs to be finished when the user calls app.listen() because end-users might end up seeing files that aren't completely built yet otherwise. But it shouldn't be a problem (I think) with syncronous hooks.

What do you think about this

var vendorReplace = function(code) {
  code = ...  /*replace*/
  return code
}
BundleUp(app, __dirname + '/assets', {
  staticRoot: __dirname + '/public/',
  staticUrlRoot:'/',
  bundle:true
  hooks: {
    css:[vendorReplace, base64UrlReplace]
    js:[/*some js magic*/]
  }
});

[panosru]

I love it the way you structured it :)

PS: Not everyone cared about API or architecture any more today ;) well done

[panosru]

one question though... why I have to do BundleUp(app, .... instead of app.use(... ?

[panosru]

I don't know if I'm taking it too far, but should hooks be event based ? so you could have something like this:

hooks : {
    preMinify : {
        css : [],
        js : []
    },
    postMinify : { }
}

So different hooks would applied on different state.

Now personally I'm not sure if this could be useful for someone but if you think that it won't be useful then consider the fact for hooks to be applied before the minification method.

[Cowboy-coder]

The reason you need to pass app is because the view helpers are added on the app object.

I agree with you on the hooks, having an option before and after minification is probably a good thing.

[martinmcwhorter]

How about image support using a stylus hook?

in style.styl background: image('check.png')

gets rendered as background: url('/public/generated/images/check-somehash.png')

/assets/images/check.png gets copied to /public/generated/images/check-somehash.png

[Cowboy-coder]

Yeah, I have thought about that. However i'm thinking about simplifying it a bit, by just using a querystring parameter. I.e

background: url(/assets/images/check.png); becomes background: url(/assets/images/check.png?v=1234); It seems a bit too annoying to actually copy the files. It adds up on start time for the server.

And as far as I know using query strings is in most cases as good as renaming files as a cache-busting technique.

[martinmcwhorter]

Let me make the case for copying the file and using a file with checksum appended to the name instead of a version query-string. The ability to serve many versions of an asset durring a rolling deployment.

Example:

• Durring a deployment, client that begin their session before the deploy may be requesting check-hash1.png, which is appropriate for the CSS asset they have received.
  • Clients that begin their activity after the deploy would get check-hash2.png, which would correspond to the other images and css assets it has received.

This does seem like an edge case, but I have seen this very issue come up again and again in production environments with rolling deployments and assets were not versioned correctly.

This is one of the problems that the Rails 3 asset-pipeline solves.