Javascript is an essential tool for building great user interfaces these days, and has some really mature tools for getting a great development environment. One problem I’ve had is there are many different ways to hooks these tools together.<\/p>\n
After a lot of trial and error, I found a set that seems to work pretty well for me across different javascript frameworks.<\/p>\n
This feels like a pretty high bar, but javascript has some crazy capabilities, and it’d be a shame not to use them.<\/p>\n
I use npm<\/a> as a task runner and for dependencies. It also seems like everything published to bower<\/a> is also published to npm<\/a>, so I’m happy to skip other package managers. Just don’t look too closely in the The npm scripts<\/a> are effective for defining tasks without needing to install things globally nor edit my I generally make a few custom tasks:<\/p>\n I also tend to make subtasks, and chain them together using the limited syntax that is shared between I use browserify<\/a> for an awful lot of things. It’s my compiler, translator, minifier, and bundler. I tend to think of it all as compilation, but that’s a simplification.<\/p>\n The most basic feature is using nodejs modules<\/a> to write my code in many files and specify the dependencies between them using exorcist<\/a> creates a separate source map file from the browserify output. This is really useful for testing, since most browsers will load up the source map automatically and show you you’re actual source code in the debugger instead of whatever unreadable garbage that actually gets executed.<\/p>\n Most of the browserify<\/a> functionality comes through plugins:<\/p>\n This is probably the first bit of javascript build tooling I ever figured out, and I’ve been using it every since. karma<\/a> has a “watch” option where it will keep re-running tests as code changes.<\/p>\n The “reload-as-you-edit” features are part of what make javascript such a productive environment for user interfaces, especially when you have multiple monitors. I love having a browser \/ terminal on one monitor showing the UI and test output, and then my editor on another monitor. It’s really great to be able to simply save a file and glance over and see if my tests pass or the UI looks alright.<\/p>\n All in all that’s 29 direct dependencies<\/em>, and probably hundreds or thousands of indirect dependencies. That still feels crazy to me, but I think that’s mostly because I have to hook it all up myself. Something like eclipse or visual studio has a ton of moving parts, but it’s one installer so I tend not to think about it. You can see some examples on some of my hobby projects: c4-lab<\/a>, chore-cat<\/a>, and kpi-me<\/a>.<\/p>\n There’s room for improvement (e.g. debugging tests, speed), but this setup has worked out pretty well for me. In my last post<\/a> I decided against it, but then found some more tools that really brought it all together.<\/p>\n Most of these kinds of setups include grunt<\/a> or gulp<\/a>, but I haven’t really needed them. Between npm scripts<\/a>, browserify<\/a>, endless plugins, and shell redirection I can accomplish the same results with one less dependency and config file. I feel like if I did adopt grunt<\/a> or gulp<\/a>, I’d basically have the same setup, but with their plugins instead of browserify<\/a> plugins.<\/p>\n","protected":false},"excerpt":{"rendered":" Javascript is an essential tool for building great user interfaces these days, and has some really mature tools for getting a great development environment. One problem I’ve had is there are many different ways to hooks these tools together. After a lot of trial and error, I found a set that seems to work pretty […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[54,38,53],"tags":[],"class_list":["post-308","post","type-post","status-publish","format-standard","hentry","category-browserify","category-javascript","category-npm"],"_links":{"self":[{"href":"http:\/\/ryepup.unwashedmeme.com\/blog\/wp-json\/wp\/v2\/posts\/308","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/ryepup.unwashedmeme.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/ryepup.unwashedmeme.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/ryepup.unwashedmeme.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/ryepup.unwashedmeme.com\/blog\/wp-json\/wp\/v2\/comments?post=308"}],"version-history":[{"count":7,"href":"http:\/\/ryepup.unwashedmeme.com\/blog\/wp-json\/wp\/v2\/posts\/308\/revisions"}],"predecessor-version":[{"id":315,"href":"http:\/\/ryepup.unwashedmeme.com\/blog\/wp-json\/wp\/v2\/posts\/308\/revisions\/315"}],"wp:attachment":[{"href":"http:\/\/ryepup.unwashedmeme.com\/blog\/wp-json\/wp\/v2\/media?parent=308"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/ryepup.unwashedmeme.com\/blog\/wp-json\/wp\/v2\/categories?post=308"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/ryepup.unwashedmeme.com\/blog\/wp-json\/wp\/v2\/tags?post=308"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}node_modules<\/code> folder, it’s madness in there.<\/p>\n$PATH<\/code>. Any node-based CLI tools installed to the local node_modules<\/code> folder via npm install<\/code> are automatically on the $PATH<\/code> when using npm scripts<\/a>. I’d rather spend a little disk space than manage the unintended consequences of shared global state. It also helps reduce setup time for other developers. We can get away with just git clone && npm install && npm start<\/code>.<\/p>\n\n
npm start<\/code> – start a local webserver and spin up a bunch of filesystem watchers to run tests and refresh my browser<\/li>\nnpm run build<\/code> – create a final bundle for distribution<\/li>\nnpm run ci<\/code> – run tests and static analysis for continous integration bots<\/li>\n<\/ul>\nsh<\/code> and cmd.exe<\/code>.<\/p>\nexorcist<\/a> + browserify<\/a> + plugins for compilation<\/h3>\n
require<\/code> statements at the top of each file. This nicely mirrors imports in every other programming environment (e.g. using<\/code> in C#, import<\/code> in python, require<\/code>, require_once<\/code>, include<\/code> in php, etc).<\/p>\n\n
require('.\/foo.css')<\/code><\/li>\n\n
eslint<\/a> + karma<\/a> + jasmine<\/a> + phantomjs<\/a> + plugins for testing<\/h3>\n
\n
\n
require<\/code>, and calcuate code coverage<\/li>\nwatchify<\/a> + live-server<\/a> + npm-run-all<\/a> for active development<\/h3>\n
\n
Conclusion<\/h2>\n