So it's Christmas vacation, the new year to be exact. While others are partying and getting fat with food, I am... I don't know... 12 hours into trying to convert the module system we use at work from RequireJS to Browserify. And while I'm at it, I'll just throw in ES6 support as well...
Which I just succeeded 5 hours into the first day of the new year.
So I did a bit of research on how to get Browserify into Django. I don't want the way most developers use Browserify, where you have a watcher task monitoring the files and rebundling after changes. This presents a weird overhead, especially to those who are not into the weirdness of front-end tooling. What I wanted was minimal configuration, everything handled by packages, and where a regular developer can just write code into a file, pop it in a page and refresh.
What I got was django-pipeline-browserify, a Browserify compiler django-pipeline package as base. This was the perfect tool since pipeline takes care of the compilation. All the developer needs to do is have pipeline point to an entrypoint file where browserify will start compiling. All the rest will be as easy as
require()ing files as if it were normal JS.
Since we're dealing with JS and ES6 is coming in fast, probably standardized by the middle of 2015, I just had to pop it into the setup so that we can start ahead of the pack. What I got was a transform module called
6to5ify, which uses the 6to5 transpiler, whose transpiled code is very readable.
Now, the 12 hours wasn't a result of slacking off. It was actually because of gotchas that I didn't anticipate in the tooling. First off is that Browserify makes scripts act like Node.js modules. Even the module resolution is crazy similar to Node.js, where it looks local first and climbs up to ancestors.
The next thing that caught me was how django-pipeline works. What happens is that django copies the entire
static folder to a temporary location, transforms the files there and serves them.
The problem was, my
package.json was outside
static, which also meant
node_modules directory was also outside. This resulted in
6to5ify not being found by Browserify. The solution was to create a secondary
static for the modules Browserify will be using. Why a second? Because the first
package.json, which is at the root of the project, housed modules for unit testing. I didn't want to use symlinks nor duplicate dependencies in 2 places.
With the setup in place, I finally got rid of RequireJS complexity and also allowed me to write my very first, non-REPL, ES6 code in an actual project. The very first code was:
[1,2,3].forEach(x => alert(x));
...because lambdas were the simplest to create and easiest to remember.
Hmm... here's a checklist of what I aim to do:
Get rid of Bower entirely and use npm for package management. Makes it easier for devs, since npm ships with Node.js already and most libs are on npm anyways.
Transform all our components over to Browserify-compatible ones. While our component syntax will not change, the requirement for a transform we use is to have a custom extention. It will merely be a rename operation.
Convert to ES6 where possible. ES6 syntax provides some nice shorthands which can simplify the code. Most notable are lambdas and module syntax.