javascript | code for now

browserify, jquery, and jquery plugins

i’ve been playing around with browserify and i’m still debating whether or not it’s really the next big thing for me. complicating my development with a build process needs to buy me something that i really want. the whole concept of browserify is to be able use commonjs modules in the browser by bundling all of your dependencies together. what does that really mean? it means that your server side and client side code can look very, very similar. in fact, you can even use the same node modules that you used on the back end in the front end.

this lets you write code that looks like:

var moduleA = require('./moduleA');
var moduleB = require('./moduleB');

moduleA.foo();
moduleB.bar();

var moduleA = require('./moduleA');

var moduleB = require('./moduleB');

moduleA.foo();

moduleB.bar();

to be able to work out all of the dependencies that your javascript has, a grunt task is introduced to scan through your javascript and include all of the dependencies found within your “require”d code.

that spoke to me quite a bit because i liked the fact that my front and back end code now looked very similar. but then i ran into a hiccup. what about jquery? it turns out that jquery works reasonably well if you just require it, but where i got stuck for a while is what if you wanted to use a jquery plugin?

i’m not completely sure that this is the right way to do it, but it works:

var $ = require('./jquery-1.11.1.min');
window.$ - $;
window.jQuery = $;
var plugin = require('./jquery-plugin');

$(document).ready(function() {
    $('body').plugin();
});

var $ = require('./jquery-1.11.1.min');

window.$ - $;

window.jQuery = $;

var plugin = require('./jquery-plugin');

$(document).ready(function() {

$('body').plugin();

});

what’s different? binding $ and jQuery into global scope seems to be the key here. and actually, all you really need is window.jQuery, but I like having $ in global scope so i throw that in. but the question is why does this work?

if you look at any jquery plugin boilerplate, what it looks like is:

(function($) {
    $.fn.plugin = function() {};
}(jQuery));

(function($) {

$.fn.plugin = function() {};

}(jQuery));

the plugin is expecting to find the jQuery object in global scope. usually, when jquery is included in the page, this happens automatically, but because of the way that jQuery is loaded via browserify, this isn’t happening. so the above hack just inserts it into global scope so that the plugin can find what it wants to then define itself.

it all seems to make sense, but it feels like there’s got to be a better way to do it. i just can’t figure out what that better way is. but i can’t get over the fact that it feels dirty to me that i need to write additional code just because i’m using browserify. it just feels like i’m doing something wrong here.

using livereload without the browser plugin

livereload is a little project that dramatically changes a front end developer’s life. it watches the filesystem for changes and will tell the browser to reload the page if it detects changes on the filesystem.

the idea by itself is pretty awesome. the actual implementation of this is a little weird as there appears to be a standalone app and a browser plugin that communicates with each other to detect the file changes and then trigger a browser reload.

but wait, there’s something even cooler! the livereload node module is an implementation of the livereload server in node.js. you can hook this into your node application and then you won’t need a separate app to monitor for file changes in your codebase. but still, there is some friction here because you still need that browser plugin so that the livereload server can trigger a browser reload.

but if you look at what the plugin does, all it does is inject some javascript on the page to call the livereload server, load up a javascript file, and initiate the websocket connection to listen for triggers. it turns out that you can simply add that script call to your page and then you won’t need the browser plugin at all.

it is technically documented but buried pretty deep in the knowledge base.

livereload is a separate server running in your app, so you just need to stick the code somewhere after your main server has been initiated, i put it at the buttom of my server.js file.

var livereload = require('livereload');

var server = livereload.createServer({
    exts: [
        'dust'
    ]
});

server.watch(__dirname + '/config');
server.watch(__dirname + '/controllers');
server.watch(__dirname + '/lib');
server.watch(__dirname + '/locales');
server.watch(__dirname + '/models');
server.watch(__dirname + '/public');

var livereload = require('livereload');

var server = livereload.createServer({

exts: [

'dust'

]

});

server.watch(__dirname + '/config');

server.watch(__dirname + '/controllers');

server.watch(__dirname + '/lib');

server.watch(__dirname + '/locales');

server.watch(__dirname + '/models');

server.watch(__dirname + '/public');

livereload accepts a parameter “exts” which tells it which file extensions to watch. you can add as many server.watch() paths as you want for directories to watch.

then you just need to add this snippet to the bottom of your page template to have the browser connect the livereload server with your app:

<script>
    document.write('<script src="http://' + (location.host || 'localhost').split(':')[0] + ':35729/livereload.js?snipver=1"></' + 'script>');
</script>

document.write('<script src="http://' + (location.host || 'localhost').split(':')[0] + ':35729/livereload.js?snipver=1"></' + 'script>');

</script>

and voila, if you make an update to a file in your project, your browser will automatically reload for you.

Integrating JavaScript linters in Jenkins

I use two linters to lint my JavaScript: JSHint and Google Closure Linter. I use JSHint primarily to check for JavaScript code best practices and rely on Google Closure Linter for style convention enforcement. This combination of linters is run in real time for me via the SublimeLinter package in Sublime Text Editor.

Usually that leads to pretty clean code for me, but for others who contribute to the project, I needed to make sure that their code passed the same tests. It turns out that I haven’t found a good solution for integrating JSHint and the Closure linter into Jenkins.

I’ve decided for now to just run them as build steps that run command line programs, but surely there must be a better way. Isn’t there?

Getting the output of these tools to be picked up by the Violations plugin in Jenkins isn’t terribly difficult, there’s some massaging of the output needed for the Closure linter, but luckily JSHint exports it in a Violations-friendly format.

It took me about 15 minutes to figure out how to run jshint recursively.

jshint .

jshint .

Of course, it was that easy.

JavaScript source code indexing with Sublime Text Editor with ctags

As a JavaScript developer, IDEs are still relatively immature and some very basic features available in other languages are hard to find for JavaScript. A killer feature in Eclipse for other languages like Java is its ability to open declarations. What this does is provide you the ability to look up symbols.

Before, I’d have to look through code to try to understand where a particular JavaScript object is, but there’s a better way to do it.

Exuberant Ctags provides a mechanism to index your source code and create a map of all of the symbols it finds in your code.

The CTags package for Sublime adds Ctags support to Sublime. Ctags generates an index (or tag) file of language objects so that they can be quickly and easily located by a text editor.

Exuberant Ctag’s support for modern JavaScript is not great, but you can help it along by giving it some hints via a file ~/.ctag. You should put the following from Tim’s gist:

--langdef=js
--langmap=js:.js
--regex-js=/(,|(;|^)[ \t]*(var|let|([A-Za-z_$][A-Za-z0-9_$.]+\.)*))[ \t]*([A-Za-z0-9_$]+)[ \t]*=[ \t]*\{/\5/,object/
--regex-js=/(,|(;|^)[ \t]*(var|let|([A-Za-z_$][A-Za-z0-9_$.]+\.)*))[ \t]*([A-Za-z0-9_$]+)[ \t]*=[ \t]*function[ \t]*\(/\5/,function/
--regex-js=/(,|(;|^)[ \t]*(var|let|([A-Za-z_$][A-Za-z0-9_$.]+\.)*))[ \t]*([A-Za-z0-9_$]+)[ \t]*=[ \t]*\[/\5/,array/
--regex-js=/(,|(;|^)[ \t]*(var|let|([A-Za-z_$][A-Za-z0-9_$.]+\.)*))[ \t]*([A-Za-z0-9_$]+)[ \t]*=[ \t]*[^"]'[^']*/\5/,string/
--regex-js=/(,|(;|^)[ \t]*(var|let|([A-Za-z_$][A-Za-z0-9_$.]+\.)*))[ \t]*([A-Za-z0-9_$]+)[ \t]*=[ \t]*(true|false)/\5/,boolean/
--regex-js=/(,|(;|^)[ \t]*(var|let|([A-Za-z_$][A-Za-z0-9_$.]+\.)*))[ \t]*([A-Za-z0-9_$]+)[ \t]*=[ \t]*[0-9]+/\5/,number/
--regex-js=/(,|(;|^)[ \t]*(var|let|([A-Za-z_$][A-Za-z0-9_$.]+\.)*))[ \t]*([A-Za-z0-9_$]+)[ \t]*=[ \t]*.+([,;=]|$)/\5/,variable/
--regex-js=/(,|(;|^)[ \t]*(var|let|([A-Za-z_$][A-Za-z0-9_$.]+\.)*))[ \t]*([A-Za-z0-9_$]+)[ \t]*[ \t]*([,;]|$)/\5/,variable/
--regex-js=/function[ \t]+([A-Za-z0-9_$]+)[ \t]*\([^)]*\)/\1/,function/
 
--regex-js=/(,|^)[ \t]*([A-Za-z_$][A-Za-z0-9_$]+)[ \t]*:[ \t]*\{/\2/,object/
--regex-js=/(,|^)[ \t]*([A-Za-z_$][A-Za-z0-9_$]+)[ \t]*:[ \t]*function[ \t]*\(/\2/,function/
--regex-js=/(,|^)[ \t]*([A-Za-z_$][A-Za-z0-9_$]+)[ \t]*:[ \t]*\[/\2/,array/
--regex-js=/(,|^)[ \t]*([A-Za-z_$][A-Za-z0-9_$]+)[ \t]*:[ \t]*[^"]'[^']*/\2/,string/
--regex-js=/(,|^)[ \t]*([A-Za-z_$][A-Za-z0-9_$]+)[ \t]*:[ \t]*(true|false)/\2/,boolean/
--regex-js=/(,|^)[ \t]*([A-Za-z_$][A-Za-z0-9_$]+)[ \t]*:[ \t]*[0-9]+/\2/,number/
--regex-js=/(,|^)[ \t]*([A-Za-z_$][A-Za-z0-9_$]+)[ \t]*:[ \t]*[^=]+([,;]|$)/\2/,variable/

--langdef=js

--langmap=js:.js

--regex-js=/(,|(;|^)[ \t]*(var|let|([A-Za-z_$][A-Za-z0-9_$.]+\.)*))[ \t]*([A-Za-z0-9_$]+)[ \t]*=[ \t]*\{/\5/,object/

--regex-js=/(,|(;|^)[ \t]*(var|let|([A-Za-z_$][A-Za-z0-9_$.]+\.)*))[ \t]*([A-Za-z0-9_$]+)[ \t]*=[ \t]*function[ \t]*\(/\5/,function/

--regex-js=/(,|(;|^)[ \t]*(var|let|([A-Za-z_$][A-Za-z0-9_$.]+\.)*))[ \t]*([A-Za-z0-9_$]+)[ \t]*=[ \t]*\[/\5/,array/

--regex-js=/(,|(;|^)[ \t]*(var|let|([A-Za-z_$][A-Za-z0-9_$.]+\.)*))[ \t]*([A-Za-z0-9_$]+)[ \t]*=[ \t]*[^"]'[^']*/\5/,string/

--regex-js=/(,|(;|^)[ \t]*(var|let|([A-Za-z_$][A-Za-z0-9_$.]+\.)*))[ \t]*([A-Za-z0-9_$]+)[ \t]*=[ \t]*[0-9]+/\5/,number/

--regex-js=/function[ \t]+([A-Za-z0-9_$]+)[ \t]*$[^)]*$/\1/,function/

--regex-js=/(,|^)[ \t]*([A-Za-z_$][A-Za-z0-9_$]+)[ \t]*:[ \t]*\{/\2/,object/

--regex-js=/(,|^)[ \t]*([A-Za-z_$][A-Za-z0-9_$]+)[ \t]*:[ \t]*function[ \t]*\(/\2/,function/

--regex-js=/(,|^)[ \t]*([A-Za-z_$][A-Za-z0-9_$]+)[ \t]*:[ \t]*\[/\2/,array/

--regex-js=/(,|^)[ \t]*([A-Za-z_$][A-Za-z0-9_$]+)[ \t]*:[ \t]*[^"]'[^']*/\2/,string/

--regex-js=/(,|^)[ \t]*([A-Za-z_$][A-Za-z0-9_$]+)[ \t]*:[ \t]*(true|false)/\2/,boolean/

--regex-js=/(,|^)[ \t]*([A-Za-z_$][A-Za-z0-9_$]+)[ \t]*:[ \t]*[0-9]+/\2/,number/

--regex-js=/(,|^)[ \t]*([A-Za-z_$][A-Za-z0-9_$]+)[ \t]*:[ \t]*[^=]+([,;]|$)/\2/,variable/

Mac OS X install directions:

Install Ctags. Mac OS X comes with a version of ctags already which is not the Exuberant Ctags version, so you’ll want to move it some other location if you use a package manager like homebrew to install it.

Shell

sudo mv /usr/bin/ctags /usr/bin/ctags.osx brew install ctags

1
2

sudo mv /usr/bin/ctags /usr/bin/ctags.osx
brew install ctags
In Sublime Text Editor, install the CTags package via the Package Control.
Create the file ~/.ctags and put into it whatever is in this gist: ctags definition for JavaScript.
Open your favorite project and build the ctags for the project via the “CTRL-T, CTRL-R” key sequence.
Find a piece of your code where you want to open a declaration and “CTRL-T, CTRL-T” to see if ctags can bounce you over to the relevant piece of code. It’s not perfect and can’t always do it for you, but it’s pretty darn good.

Fixing jslint and jshint errors

Anytime you write JavaScript code, you should lint your code. Linting code helps you write better JavaScript code. Linters are a form of static code analysis which will scan through your code and identify potential problems that it may find in your code.

The transition from going from not linting your code at all to writing code that is lint-free is a bit of struggle at first. What do all of these linting errors mean? Sometime I will end up having to google what a particular lint error means and how to fix it.

Well, those days are gone thanks to JSLint Error Explanations. They even have sample code which demonstrates the linting error and tells you hot to fix it. Pretty nice.

The only annoying thing about the site is the “Fork me in GitHub ribbon” on the upper right that is fixed in that corner even if you scroll.

Speaking of linting, I also highly recommend Google Closure’s linter. It comes with a tool that will automatically fix style issues that it finds for you. Very handy and easy to use, though the install is a little bit of a pain.

And lastly, for Sublime Text Editor users, if you want to use multiple linting engines on the fly with the excellent SublimeLinter package, you can check out my fork of the SublimeLinter that calls multiple engines instead of just one.

S	M	T	W	T	F	S
« Nov
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

code for now

Category Archives: javascript

browserify, jquery, and jquery plugins

using livereload without the browser plugin

Integrating JavaScript linters in Jenkins

JavaScript source code indexing with Sublime Text Editor with ctags

Fixing jslint and jshint errors

Recent Posts

Recent Comments

Archives

Calendar

Categories