Make a decision on external dependencies.

[markhibberd]

@marlimox There are a few things I am not sure about and possibly are at odds with past decisions:

• What to do about things like karma test runner? Should the npm package depend on it? Do we add commands for it that just fail if it is not available? Do we not add anything except what we have now (i.e. bolt "can" be used with karma, but has no baked in support)?
• What to do about things that are not "bolt" but are always going to be done a lot by bolt projects. Specifically minification/gzip/css inlining? You know my general preference is to make these separate tools, but it is also somewhat uncomfortable that bolt build is not complete, in the sense I will still need to wrap a Makefile or similar around everything to have a "complete" build pipeline which is not great.

[marlimox]

Yeah this is a tricky question. There's another part to it as well: what to do about third-party dependencies that bolt itself has.

For instance, looking at this globbing stuff, the only real sensible choice I can find to do globbing on the node side is node-glob (https://github.com/isaacs/node-glob, although it has one minor suckage in that on windows it doesn't support backslashes in paths, so we'll have to find a way to fix that because wintards will definitely pass in backslashed paths). But anyway, how do we depend on this library? Copy and package the source ourselves and ship it with bolt? Add it as a npm dependency?

A couple of things come to mind:

• If we use npm dependencies for anything core, then we can no longer effectively support the tar.gz install process, we are forcing people to use npm. And I'm surely not the only person in the world with npm-rage. Whatever happens, I still want to be able to go: 1. install node. 2. unzip bolt dist and add to path. 3. bolt works. So in my mind using only npm dependencies is pretty much out. Do you agree?
• Copy core third-party dependencies into bolt directly in a third_party directory. This seems like the best thing to do for small, core dependencies such as node-glob. It keeps bolt's external dependencies to a minimum and gives us some control of the third-party dependencies we have that are integral to bolt working. Not sure what you think about this.
• Package and ship everything with bolt. karma, minification tools, css inlining, etc. I don't think this would scale very well though. It would be nice to support lots of different tools for doing these other jobs, and allow people to choose, rather than force them to use a particular tool.
• We could use a hybrid approach where we do use npm dependencies but provide another way to obtain dependencies if bolt wasn't installed via npm. For instance, have a 'bolt install' sub-command that will fetch things like karma, or will fetch additional bolt functionality like adding a 'bolt browser' command. We talked about this in the past for the old bolt browser, because it was too big to include in a default distribution.
• Don't use npm dependencies at all, but running with the last point write our own really simple package management for installing additional bolt functionality. Really this seems like the most scalable solution and doesn't tie bolt too much to specific tools. 'bolt install karma', could install a 'bolt karma' sub-command, support project configuration from 'build.karma' in project.json. The only question is would that install karma itself or not? It could literally do an npm install karma. Or it could expect the user to install karma themselves via whichever means works for them. Running 'bolt karma' after 'bolt install karma', without having karma installed, could prompt them with a "you need to install karma to use this command, run npm install karma, etc. etc." message. This approach could work for minification tools, etc. as well.

If we fleshed this out a bit, this could provide a nice standard way of extending bolt with additional sub-commands outside of a small core set (basically init, build, test, clean). We could also add hooks into the built in sub-commands to run additional commands as part of their process.

For instance, bolt build could have an option to run other commands when its done, or at other points in the process, so you could say after bolt build, run minify, css-inline. Not sure about this, just random thoughts for how to make the idea generally extensible to different tools and workflows.

You know my general preference is to make these separate tools, but it is also somewhat uncomfortable that bolt build is not complete, in the sense I will still need to wrap a Makefile or similar around everything to have a "complete" build pipeline which is not great.

I still think these should definitely be separate tools. The only question is how to integrate them with bolt.

[markhibberd]

I am good with pulling in node-glob (and similar) to a third party directory. We don't have that luxury with everything though, and I am not sure npm or more difficult manual configuration can be avoided - for example phantom needs native components which mean anything simple is off the books. Need to think this through, but it is an obvious pain point at the moment.

[marlimox]

Ah native components. Yeah that's going to throw a spanner in the works as well.