Related
The Chrome Dev Tools JavaScript and CSS Coverage Drawer is pretty neat, except for one thing... It would be nice if it could be left on, and not reinitiate its analysis between pages.
I would like to be able to analyze an entire site, a subset of pages, or a set of websites, and find what is unused amongst them.
I get that it would mean browsing entire projects and using every feature (or setting up tests) to be thorough/precise, but that's not as tedious as what I have to do entirely without such a utility/feature. (And it doesn't seem like you would need to be meticulous to obtain usable or initial observations from a sub-thorough audit. The DevTools utility doesn't facilitate automated tests on its own either.)
The codebase at issue is huge (1.9mb uncompressed on the front end), and (possibly) contributed to by many developers who may or may not have left relics, legacy code, or abandoned dependencies. There is possibly also code that is only relevant in parts of projects, which could reveal opportunities for reducing dependency scope.
Is there a way to begin to crack into code use without a laborious manual deep dive?
It was one of the first things that came to mind when learned about the Google's coverage utility, and I assumed it would be capable of analyzing multiple pages collectively, but it doesn't.
Is there anything else that does this? Does any utility exist that can search an entire site or multiple pages and find unused JS and CSS?
Side note: The CSS is in SASS. For that and other reasons I may need to manually analyze the results and improve the code, which is trivial comparatively, so I'm not looking for a feature to automate code improvements. It's a similar situation with the JS which is minified.
This is not a request for a recommendation on poduct/software. It is asking if task X is possible, which is technically answerable with a yes or no.
UPDATE: It does seem like there are utilities for CSS, but still nothing found for JS.
For Static Analysis:
Try unusedcss.com to analyse unused CSS code across the entire website. More - Helium CSS
Try deadfile which is a simple util to find deadcode and unused files in any JavaScript project.
For Dead-code Removal:
Try purgecss to remove unused CSS code from your project.
Try Google's closure compiler which parses your JavaScript, analyzes it, removes dead code and rewrites and minimizes what's left.
That being said, detecting unused code is a hard problem to solve, because there are countless ways to invoke a given piece of code. Hence, these tools wisely and with your best judgement.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I want to make a JavaScript application that's not open source, and thus I wish to learn how to can obfuscate my JS code? Is this possible?
Obfuscation:
Try YUI Compressor. It's a very popular tool, built, enhanced and maintained by the Yahoo UI team.
You may also use:
Google Closure Compiler
UglifyJS
UPDATE: This question was originally asked on 2008, and The mentioned technologies are deprecated. you can use:
terser - more information in web.dev.
Private String Data:
Keeping string values private is a different concern, and obfuscation won't really be of much benefit. Of course, by packaging up your source into a garbled, minified mess, you have a light version of security through obscurity. Most of the time, it's your user who is viewing the source, and the string values on the client are intended for their use, so that sort of private string value isn't often necessary.
If you really had a value that you never wanted a user to see, you would have a couple of options. First, you could do some kind of encryption, which is decrypted at page load. That would probably be one of the most secure options, but also a lot of work which may be unnecessary. You could probably base64 encode some string values, and that would be easier.. but someone who really wanted those string values could easily decode them. Encryption is the only way to truly prevent anyone from accessing your data, and most people find that to be more security than they need.
Sidenote:
Obfuscation in Javascript has been known to cause some bugs. The obfuscators are getting a little better about it, but many outfits decide that they see enough benefit from minifying and gzipping, and the added savings of obfuscation isn't always worth the trouble. If you're trying to protect your source, maybe you'll decide that it's worth your while, just to make your code harder to read. JSMin is a good alternative.
I'm surprised no one has mentioned Google's Closure Compiler. It doesn't just minify/compress, it analyzes to find and remove unused code, and rewrites for maximum minification. It can also do type checking and will warn about syntax errors.
JQuery recently switched from YUI Compresser to Closure Compiler, and saw a "solid improvement"
Obfuscation can never really work. For anyone who really wants to get at your code, it's just a speed bump. Worse, it keeps your users from fixing bugs (and shipping the fixes back to you), and makes it harder for you to diagnose problems in the field. Its a waste of your time and money.
Talk to a lawyer about intellectual property law and what your legal options are. "Open Source" does not mean "people can read the source". Instead, Open Source is a particular licensing model granting permission to freely use and modify your code. If you don't grant such a license then people copying your code are in violation and (in most of the world) you have legal options to stop them.
The only way you can really protect your code is to not ship it. Move the important code server-side and have your public Javascript code do Ajax calls to it.
See my full answer about obfuscators here.
You can obfuscate the javascript source all you want, but it will always be reverse-engineerable just by virtue of requiring all the source code to actually run on the client machine... the best option I can think of is having all your processing done with server-side code, and all the client code javascript does is send requests for processing to the server itself. Otherwise, anyone will always be able to keep track of all operations that the code is doing.
Someone mentioned base64 to keep strings safe. This is a terrible idea. Base64 is immediately recognizable by the types of people who would want to reverse engineer your code. The first thing they'll do is unencode it and see what it is.
There are a number of JavaScript obfuscation tools that are freely available; however, I think it's important to note that it is difficult to obfuscate JavaScript to the point where it cannot be reverse-engineered.
To that end, there are several options that I've used to some degree overtime:
YUI Compressor. Yahoo!'s JavaScript compressor does a good job of condensing the code that will improve its load time. There is a small level of obfuscation that works relatively well. Essentially, Compressor will change function names, remove white space, and modify local variables. This is what I use most often. This is an open-source Java-based tool.
JSMin is a tool written by Douglas Crockford that seeks to minify your JavaScript source. In Crockford's own words, "JSMin does not obfuscate, but it does uglify." It's primary goal is to minify the size of your source for faster loading in browsers.
Free JavaScript Obfuscator. This is a web-based tool that attempts to obfuscate your code by actually encoding it. I think that the trade-offs of its form of encoding (or obfuscation) could come at the cost of filesize; however, that's a matter of personal preference.
What i would do:
A. Troll the hacker!
This is will be in the second part my fake/obfuscated secret javascript code LAUNCHER.
The one you see in the source code.
What does this code?
loads the real code
sets a custom header
posts a custom variable
var ajax=function(a,b,d,c,e,f){
e=new FormData();
for(f in d){e.append(f,d[f]);};
c=new XMLHttpRequest();
c.open('POST',a);
c.setRequestHeader("Troll1","lol");
c.onload=b;
c.send(e);
};
window.onload=function(){
ajax('Troll.php',function(){
(new Function(atob(this.response)))()
},{'Troll2':'lol'});
}
B. Obfuscate the code a little
What is that?
thats the same code as above in base64
this is not the SECRET javascript code
(new Function(atob('dmFyIGFqYXg9ZnVuY3Rpb24oYSxiLGQsYyxlLGYpe2U9bmV3IEZvcm1EYXRhKCk7Zm9yKGYgaW4gZCl7ZS5hcHBlbmQoZixkW2ZdKTt9O2M9bmV3IFhNTEh0dHBSZXF1ZXN0KCk7Yy5vcGVuKCdQT1NUJyxhKTtjLnNldFJlcXVlc3RIZWFkZXIoIlRyb2xsMSIsImxvbCIpO2Mub25sb2FkPWI7Yy5zZW5kKGUpO307d2luZG93Lm9ubG9hZD1mdW5jdGlvbigpe2FqYXgoJ1Ryb2xsLnBocCcsZnVuY3Rpb24oKXsgKG5ldyBGdW5jdGlvbihhdG9iKHRoaXMucmVzcG9uc2UpKSkoKX0seydUcm9sbDInOidsb2wnfSk7fQ==')))()
C Create a hard to display php file with the real code inside
What does this php code?
Checks for the right referrer (domain/dir/code of your launcher)
Checks for the custom HEADER
Checks for the custom POST variable
If everything is ok it will show you the right code else a fake code or ban ip, close page.. whatever.
<?php
$t1=apache_request_headers();
if(base64_encode($_SERVER['HTTP_REFERER'])=='aHR0cDovL2hlcmUuaXMvbXkvbGF1bmNoZXIuaHRtbA=='&&$_POST['Troll2']=='lol'&&$t1['Troll1']='lol'){
echo 'ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdkaXYnKSkuaW5uZXJUZXh0PSdBd2Vzb21lJzsNCg==';//here is the SECRET javascript code
}else{
echo 'd2luZG93Lm9wZW4oJycsICdfc2VsZicsICcnKTt3aW5kb3cuY2xvc2UoKTs=';
};
?>
base64 referrer = http://here.is/my/launcher.html
SECRET javascript = document.body.appendChild(document.createElement('div')).innerText='Awesome';
FAKE = window.open('', '_self', '');window.close();
Now .. if you define event handlers in the SECRET javascript it's probably accessible.. you need to define them outside with the launchcode and pointing to a nested SECRET function.
SO... is there a easy wayto get the code?
document.body.appendChild(document.createElement('div')).innerText='Awesome';
I'm not sure if this works but i'm using chrome and checked Elements,Resources,Network,Sources,Timeline,Profiles,Audits but i didn't find the line above.
note1: if u open the Troll.php url from Inspect element->network in chrome you get the fake code.
note2: the whole code is written for modern browsers. polyfill needs alot more code.
EDIT
launcher.html
<!doctype html><html><head><meta charset="utf-8"><title></title><script src="data:application/javascript;base64,KG5ldyBGdW5jdGlvbihhdG9iKCdkbUZ5SUdGcVlYZzlablZ1WTNScGIyNG9ZU3hpTEdRc1l5eGxMR1lwZTJVOWJtVjNJRVp2Y20xRVlYUmhLQ2s3Wm05eUtHWWdhVzRnWkNsN1pTNWhjSEJsYm1Rb1ppeGtXMlpkS1R0OU8yTTlibVYzSUZoTlRFaDBkSEJTWlhGMVpYTjBLQ2s3WXk1dmNHVnVLQ2RRVDFOVUp5eGhLVHRqTG5ObGRGSmxjWFZsYzNSSVpXRmtaWElvSWxSeWIyeHNNU0lzSW14dmJDSXBPMk11YjI1c2IyRmtQV0k3WXk1elpXNWtLR1VwTzMwN2QybHVaRzkzTG05dWJHOWhaRDFtZFc1amRHbHZiaWdwZTJGcVlYZ29KMVJ5YjJ4c0xuQm9jQ2NzWm5WdVkzUnBiMjRvS1hzZ0tHNWxkeUJHZFc1amRHbHZiaWhoZEc5aUtIUm9hWE11Y21WemNHOXVjMlVwS1Nrb0tYMHNleWRVY205c2JESW5PaWRzYjJ3bmZTazdmUT09JykpKSgp"></script></head><body></body></html>
Troll.php
<?php $t1=apache_request_headers();if(/*base64_encode($_SERVER['HTTP_REFERER'])=='PUT THE LAUNCHER REFERER HERE'&&*/$_POST['Troll2']=='lol'&&$t1['Troll1']='lol'){echo 'ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdkaXYnKSkuaW5uZXJUZXh0PSdBd2Vzb21lJzsNCg==';}else{echo 'd2luZG93Lm9wZW4oJycsICdfc2VsZicsICcnKTt3aW5kb3cuY2xvc2UoKTs=';}; ?>
The problem with interpreted languages, is that you send the source to get them working (unless you have a compiler to bytecode, but then again, it is quite trivial to decompile).
So, if you don't want to sacrifice performance, you can only act on variable and function names, eg. replacing them with a, b... aa, ab... or a101, a102, etc. And, of course, remove as much space/newlines as you can (that's what so called JS compressors do).
Obfuscating strings will have a performance hit, if you have to encrypt them and decrypt them in real time. Plus a JS debugger can show the final values...
Try JScrambler. I gave it a spin recently and was impressed by it.
It provides a set of templates for obfuscation with predefined settings for those who don't care much about the details and just want to get it done quickly. You can also create custom obfuscation by choosing whatever transformations/techniques you want.
Contrary to most of the other answers I suggest against YUI Compressor; you should use Google Closure.
Not much because it compresses more, but mostly because it will catch javascript errors such as a = [1,2,3,]; which make IE go haywire.
I can recommend JavaScript Utility by Patrick J. O'Neil. It can obfuscate/compact and compress and it seems to be pretty good at these. That said, I never tried integrating it in a build script of any kind.
As for obfuscating vs. minifying - I am not a big fan of the former. It makes debugging impossible (Error at line 1... "wait, there is only one line") and they always take time to unpack. But if you need to... well.
A non-open-source Javascript-based application is fairly silly. Javascript is a client-side interpreted language.. Obfuscation isn't much protection..
JS obfuscation is usually done to reduce the size of the script, rather than "protect" it. If you are in a situation where you don't want your code to be public, Javascript isn't the right language..
There are plenty of tools around, but most have the word "compressor" (or "minifier") in its name for a reason..
You can't secure client side code: just press F12 on Google Chrome, pause javascript execution and you will get all strings, even those encrypted. Beautify it and rename variables and you will get almost the original code.
If you're writing server side javascript (i.e. NodeJS) is afraid of someone hacking into your server and want to make the hacker work more difficult, giving you more time to get your access back, then use javacript compilers:
You need to use Closure Compiler on Advanced Compilation, as it's the only tool that renames all your variables, even if those are used in multiple files/modules. But it just have a problem: it only work if you write in it's coding style.
I would suggest first minify with something like YUI Compressor, and then convert all string and numbers to HEX Values using something like http://www.javascriptobfuscator.com/
With this, the code would be rendered near impossible to understand and I think at this Stage it will take more time for a Hacker to re-enact your code than actually if he re-wrote from scratch. Rewriting and Cloning is what you cant actually stop. After all we are free-people !
Try this tool Javascript Obfuscator
I used it on my HTML5 game not only it reduced it size from 950KB to 150 but also made the source code unreadable closure compilers and minifiers are reversable I personally dont know how to reverse this obfuscation.
Dean Edward's Packer is an excellent obfuscator, though it primarily obfuscates the code, not any string elements you may have within your code.
See: Online Javascript Compression Tool and select Packer (Dean Edwards) from the dropdown
I'm under the impression that some enterprises (e.g.: JackBe) put encrypted JavaScript code inside *.gif files, rather than JS files, as an additional measure of obfuscation.
I've been using Jasob for years and it is hands down the best obfuscator out there.
It has an advanced UI but is still intuitive and easy to use.
It will also handle HTML and CSS files.
The best way to use it is to prefix all of your private variables with something like an underscore, then use the sort feature to group them all together and check them off as targets for obfuscation.
Users can still view your source, but it's much more difficult to decipher when your private variables are converted from something like _sUserPreferredNickName to a.
The engine will automatically tally up the number of targeted variables and prioritize them to get the maximum compression.
I don't work for Jasob and I get nothing out of promoting them, just offering some friendly advice.
The downside is that it's not free and is a little pricey, but still worth it when stacked against alternatives - the 'free' options don't even come close.
Have you tried Bananascript? It produces highly compressed and completely unreadable code.
I am using Closure-Compiler utility for the java-script obfuscation. It minifies the code and has more options for obfuscation.
This utility is available at Google code at below URL:
Closure Tools
But now a days I am hearing much of UglifyJS. You can find various comparison between Closure Compiler and UglifyJS in which Uglify seems to be a winner.
UglifyJS: A Fast New JavaScript Compressor For Node.js That’s On Par With Closure
Soon I would give chance to UglifyJS.
As a JavaScript/HTML/CSS obfuscator/compressor you can also try Patu Digua.
You definitely should consider taking a look at Obfuscriptor.
I goes beyond the typical Javascript minifying tricks we've seen from other tools such as YUI Compressor or Google Closure.
The obfuscated code looks more like encrypted. Unlike anything I've seen before.
I've used this in the past, and it does a good job. It's not free, but you should definitely take a look.
JavaScript Obfuscator & Encoder
I'm pretty new to TextMate and I just can't figure out how to make JSDoc like comment when editing .js file. I'm using the PHP bundle and there it is pretty easy - I just type doc and then tab. I've already added custom snippet but the problem is that it does not handle new lines properly (it doesn't insert trailing *).
You'll need to install a JSDoc bundle, but it doesn't look like there's much available. A quick google search did bring up something though: https://github.com/tysontate/javascript-jsdoc-tmbundle
No idea if it's any good, and it actually says that the commands don't yet work, but it appears to have seen at least some activity lately (unlike the others I found). It looks like there just aren't that many people who are using JS Doc (or, at least not that many TextMate users who are using it).
Usually, googling for "something bundle textmate" will yield the right results, but apparently JSDoc just isn't that commonly used.
However, maybe someone has added some JSDoc functionality to the existing JavaScript bundle (much like you've started doing). Didn't try looking for that, but you might get lucky.
But hey, it's a good excuse to get your hands dirty (and learn a lot about TextMate in the process) by messing around with whatever the available bundles have to offer, maybe even fixing a few bugs, and giving something back to the community (you don't have to of course, it's just a suggestion).
Not much of an answer, but hopefully you'll find our way from here
An updated bundle with tools for editing JSDoc comments in TextMate 2 is available at https://github.com/rootworkit/JsDoc-Toolkit.tmbundle
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am currently validating my JavaScript against JSLint and making progress on, it's assisting me to write better JavaScript - in particular in working with the Jquery library.
I have now come across JSHint, a fork of JSLint.
So I am wondering for web applications, which are very much JavaScript was driven, which is the better or most applicable validation tool to work against:
JSLint or JSHint?
I want to decide now on a validation mechanism and moving forward, use this for client side validation.
And Difference between jshint and jslint? Please explain in single javascript example.
Links:
jshint- http://www.jshint.com/
jslint- http://jslint.com/
TL;DR
Use JSLint if you're looking for a very high standard for yourself or your team, but bear in mind that it's not necessarily the standard, only a standard, some of which comes to us dogmatically from Doug Crockford.
If you want to be a bit more flexible or have some old pros on your team that don't buy into JSLint's opinions or are going back and forth between JavaScript and other C-family languages regularly, try JSHint.
Full version
Two articles with the reasoning behind the fork explain why JSHint exists:
JSHint: A Community-Driven Fork Of JSLint
Why I forked JSLint to JSHint
The idea behind JSLint is that it's community-driven rather than Crockford-driven. JSHint is generally more lenient (or at least configurable or agnostic) on a few stylistic and minor syntactical opinions that JSLint is a stickler for.
For example, if you think both 1. and 2. below are fine, or if you want to write code with one or more of 1.'s aspects that aren't available in 2., JSHint is for you. If you think 2. is the only correct option, use JSLint. I'm sure there are other differences, but this highlights a few.
Passes JSHint out of the box - fails JSLint
(function() {
"use strict";
var x=0, y=2;
function add(val1, val2){
return val1 + val2;
}
var z;
for (var i=0; i<2; i++){
z = add(y, x+i);
}
})();
Passes Both JSHint and JSLint
(function () {
"use strict";
var x = 0, y = 2, i, z;
function add(val1, val2) {
return val1 + val2;
}
for (i = 0; i < 2; i += 1) {
z = add(y, x + i);
}
}());
I find the JSLint code more visually appealing. The only features of it that I disagree with are its hatred of more than one var declaration in a function and of for-loop var i = 0 declarations, and some of the whitespace enforcements for function declarations.
A few of the whitespace things that JSLint enforces are not necessarily bad but are just out of sync with some pretty standard whitespace conventions for other languages in the family (C, Java, Python, etc.) often followed as conventions in Javascript as well. Since I'm writing in various of these languages throughout the day and working with team members who don't like Lint-style whitespace in our code, I find JSHint to be a good balance. It catches legitimate bugs and very badly formed code, but doesn't bark at me like JSLint does (sometimes, in ways I can't disable) for the stylistic opinions or syntactic nitpicks that I don't care for.
A lot of good libraries aren't Lint'able, which to me demonstrates that there's some truth to the idea that some of JSLint is just about pushing one version of "good code" (which is, indeed, good code). But then again, the same libraries (or other good ones) probably aren't Hint'able either, so, touché.
[EDIT]
This answer has been edited. I'm leaving the original answer below for context (otherwise the comments wouldn't make sense).
When this question was originally asked, JSLint was the main linting tool for JavaScript. JSHint was a new fork of JSLint, but had not yet diverged much from the original.
Since then, JSLint has remained pretty much static, while JSHint has changed a great deal - it has thrown away many of JSLint's more antagonistic rules, has added a whole load of new rules, and has generally become more flexible. Also, another tool ESLint is now available, which is even more flexible and has more rule options.
In my original answer, I said that you should not force yourself to stick to JSLint's rules; as long as you understood why it was throwing a warning, you could make a judgement for yourself about whether to change the code to resolve the warning or not.
With the ultra-strict ruleset of JSLint from 2011, this was reasonable advice -- I've seen very few JavaScript codesets that could pass a JSLint test. However with the more pragmatic rules available in today's JSHint and ESLint tools, it is a much more realistic proposition to try to get your code passing through them with zero warnings.
There may still occasionally be cases where a linter will complain about something that you've done intentionally -- for example, you know that you should always use === but just this one time you have a good reason to use ==. But even then, with ESLint you have the option to specify eslint-disable around the line in question so you can still have a passing lint test with zero warnings, with the rest of your code obeying the rule. (just don't do that kind of thing too often!)
[ORIGINAL ANSWER FOLLOWS]
By all means use JSLint. But don't get hung up on the results and on fixing everything that it warns about. It will help you improve your code, and it will help you find potential bugs, but not everything that JSLint complains about turns out to be a real problem, so don't feel like you have to complete the process with zero warnings.
Pretty much any Javascript code with any significant length or complexity will produce warnings in JSLint, no matter how well written it is. If you don't believe me, try running some popular libraries like JQuery through it.
Some JSLint warnings are more valuable than others: learn which ones to watch out for, and which ones are less important. Every warning should be considered, but don't feel obliged to fix your code to clear any given warning; it's perfectly okay to look at the code and decide you're happy with it; there are times when things that JSlint doesn't like are actually the right thing to do.
There is an another mature and actively developed "player" on the javascript linting front - ESLint:
ESLint is a tool for identifying and reporting on patterns found in
ECMAScript/JavaScript code. In many ways, it is similar to JSLint and
JSHint with a few exceptions:
ESLint uses Esprima for JavaScript parsing.
ESLint uses an AST to evaluate patterns in code.
ESLint is completely pluggable, every
single rule is a plugin and you can add more at runtime.
What really matters here is that it is extendable via custom plugins/rules. There are already multiple plugins written for different purposes. Among others, there are:
eslint-plugin-angular (enforces some of the guidelines from John Papa's Angular Style Guide)
eslint-plugin-jasmine
eslint-plugin-backbone
And, of course, you can use your build tool of choice to run ESLint:
grunt-eslint
gulp-eslint
I had the same question a couple of weeks ago and was evaluating both JSLint and JSHint.
Contrary to the answers in this question, my conclusion was not:
By all means use JSLint.
Or:
If you're looking for a very high standard for yourself or team, JSLint.
As you can configure almost the same rules in JSHint as in JSLint. So I would argue that there's not much difference in the rules you could achieve.
So the reasons to choose one over another are more political than technical.
We've finally decided to go with JSHint because of the following reasons:
Seems to be more configurable that JSLint.
Looks definitely more community-driven rather than one-man-show (no matter how cool The Man is).
JSHint matched our code style OOTB better that JSLint.
I'd make a third suggestion, Google Closure Compiler (and also the Closure Linter). You can try it out online here.
The Closure Compiler is a tool for making JavaScript download and run faster. It is a true compiler for JavaScript. Instead of compiling from a source language to machine code, it compiles from JavaScript to better JavaScript. It parses your JavaScript, analyzes it, removes dead code and rewrites and minimizes what's left. It also checks syntax, variable references, and types, and warns about common JavaScript pitfalls.
Foreword: Well, that escalated quickly. But decided to pull it through. May this answer be helpful to you and other readers.
Code Hinting
While JSLint and JSHint are good tools to use, over the years I've come to appreciate what my friend #ugly_syntax calls:
smaller design space.
This is a general principle, much like a "zen monk", limiting the choices one has to make, one can be more productive and creative.
Therefore my current favourite zero-config JS code style:
StandardJS.
UPDATE:
Flow has improved a lot. With it, you
can add types to your JS with will help you prevent a lot
of bugs. But it can also stay out of your way, for instance
when interfacing untyped JS. Give it a try!
Quickstart / TL;DR
Add standard as a dependency to you project
npm install --save standard
Then in package.json, add the following test script:
"scripts": {
"test": "node_modules/.bin/standard && echo put further tests here"
},
For snazzier output while developing, npm install --global snazzy and run it instead of npm test.
Note: Type checking versus Heuristics
My friend when mentioning design space referred to Elm and I encourage you to give that language a try.
Why? JS is in fact inspired by LISP, which is a special class of languages, which happens to be untyped. Language such as Elm or Purescript are typed functional programming languages.
Type restrict your freedom in order for the compiler to be able to check and guide you when you end up violation the language or your own program's rules; regardless of the size (LOC) of your program.
We recently had a junior colleague implement a reactive interface twice: once in Elm, once in React; have a look to get some idea of what I'm talking about.
Compare Main.elm (typed) ⇔ index.js (untyped, no tests)
(ps. note that the React code is not idiomatic and could be improved)
One final remark,
the reality is that JS is untyped. Who am I to suggest typed programming to you?
See, with JS we are in a different domain: freed from types, we can easily express things that are hard or impossible to give a proper type (which can certainly be an advantage).
But without types there is little to keep our programs in check, so we are forced to introduce tests and (to a lesser extend) code styles.
I recommend you look at LISP (e.g. ClojureScript) for inspiration and invest in testing your codes. Read The way of the substack to get an idea.
Peace.
Well, Instead of doing manual lint settings we can include all the lint settings at the top of our JS file itself e.g.
Declare all the global var in that file like:
/*global require,dojo,dojoConfig,alert */
Declare all the lint settings like:
/*jslint browser:true,sloppy:true,nomen:true,unparam:true,plusplus:true,indent:4 */
Hope this will help you :)
There is also an another actively developed alternative - JSCS — JavaScript Code Style:
JSCS is a code style linter for programmatically enforcing your style
guide. You can configure JSCS for your project in detail using over
150 validation rules, including presets from popular style guides like
jQuery, Airbnb, Google, and more.
It comes with multiple presets that you can choose from by simply specifying the preset in the .jscsrc configuration file and customize it - override, enable or disable any rules:
{
"preset": "jquery",
"requireCurlyBraces": null
}
There are also plugins and extensions built for popular editors.
Also see:
Perfect code, zero effort
I've recently fallen in love in WebStorm as an IDE for JavaScript development. The problem is, I come from a world of vim and lightweight editors, so I probably can't fully appreciate all the power that comes with IDE. Yes, I've seen the presentations and read the docs, but there's a lot of features and I'm not sure which of them are truly useful.
So, here goes my question: how do you use WebStorm and what do you find most useful? Any power-usage tips? Configuration hacks? Plugins worth mentioning?
I'm not looking for a list of features, I'm looking for a real-world usage examples and impressions.
PS. I work mostly with pure JS + Canvas element and some NodeJS.
Some random thoughts, maybe more later....
In the help, definitely read the Basic Concepts and skim the WebStorm Usage Guidelines for actions that you care about.
Learn to use Ctrl-Shift-A. It allows you to 1uickly find actions you can do by typing part of them. With that you can find anything once you know it exists.
WebStorm's (like IntelliJ) best magic is its code completion and refactoring features, which come from its code parsing and awareness. It figures a lot of stuff out, but you can help it out by making you have good source files. Put the commented versions of the libraries you use in your project so it can use those comments to display in the doc popups (just having them in the directory is all you need).
Be sure to leave the tips on.
Their forums are useful, but if you have a problem or feature request put it right into youtrack.com. They are much more responsive there. You can also vote for the stuff you want added.
And if you haven't seen it yet, there is a VIM plugin which will give you VIM editor keys, called IdeaVim.
Features I find most useful:
Code formatting. WebStorm's formatter is the best I've seen (of course, it still has some subtle bugs).
Built-in HTTP server: http://blog.jetbrains.com/webstorm/2013/03/built-in-server-in-webstorm-6/, How to open/debug current file using built-in Web server in WebStorm?
JsTestDriver integration.
Plugins. You can always find something useful.