Skip to content


Subversion checkout URL

You can clone with
Download ZIP
ECMAScript code beautifier/formatter
Fetching latest commit...
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


Build Status

ECMAScript code beautifier/formatter.

Why? doesn't have enough options and not all IDEs/Editors have a good JavaScript code formatter. I would like to have a command line tool (and standalone lib) as powerful/flexible as the WebStorm and FDT code formatters.

This tool could also be reused by other node.js libs like escodegen to format the output (so each lib has a single responsibility).

For more reasoning behind it and history of the project see: esformatter & rocambole


This tool uses rocambole (based on Esprima) to recursively parse the tokens and transform it in place.


  • granular control about white spaces, indent and line breaks.
  • have as many settings as possible so the user can tweak it to his own needs.
  • command line interface (cli).
  • be non-destructive.
  • option to control automatic semicolon insertion (asi).
  • support for local/global config file so settings can be shared between team members.
  • be the best JavaScript code formatter.


This tool is still on early development and is missing support for many important features.

Contributors are always welcome.

Project structure / Contributing

We will create -wip branches (work in progress) for unfinished features (mostly because of failing tests) and try to keep master only with stable code. We will try hard to not rewrite the commit history of master branch but will do it for -wip branches.

If you plan to implement a new feature check the existing branches, I will push all my local -wip branches if I don't complete the feature in the same day. So that should give a good idea on what I'm currently working.

Try to split your pull requests into small chunks (separate features), that way it is easier to review and merge. But feel free to do large refactors as well, will be harder to merge but we can work it out.

Default Settings

The default settings should be as conservative as possible, Google JavaScript Style Guide should be used as a reference.


Tests are done by comparing the result of esformatter.parse() of files with name ending on -in.js with the files -out.js. The folder test/compare/default tests the default settings and files inside test/compare/custom tests custom settings. Tests inside the compare/custom folder should try to test the opposite of the default settings whenever possible.

To run the tests install the devDependencies by running npm install --dev (only required once) and then run npm test.

mocha and expect.js source code was edited to provide better error messages. See mocha/issues/657 and expect.js/issues/34 for more info.

To check code coverage run npm test --coverage.

Popular Alternatives


Released under the MIT license

Something went wrong with that request. Please try again.