search

millermedeiros / esformatter

ECMAScript code beautifier/formatter
MIT License
970 stars 91 forks source link

format invalid JS files #206

Open millermedeiros opened 10 years ago

millermedeiros commented 10 years ago

I think we should replace esprima with acorn_loose, that way we can support ES6 features and also format files that contain JS errors.. this is a better behavior than simply displaying an error to the user.

PS: I started a branch on rocambole but there are a few differences on the loc and range info, so maybe we will introduce a few bugs...

eduardolundgren commented 10 years ago

:+1:

malko commented 9 years ago

:+1:

millermedeiros commented 9 years ago

looking at how esformatter-jsx-ignore works I think we can implement this feature as a plugin that parses the code using acorn_loose, replaces the invalid code with some comments and then restore it afterwards. - it's an ugly hack but definitely easier than replacing esprima with acorn.

millermedeiros commented 9 years ago

I was thinking more about this problem today and I think we could implement it easily inside esformatter by wrapping the rocambole.parse into a try/catch and if it fails we fallback to acorn_loose and remove all the blocks of code that are invalid and restore it afterwards (like the esformatter-jsx-ignore plugin does).

it would be better if this feature was part of the tool itself and enabled by default (think about a text editor executing esformatter at each file save or when you leave edit mode in Vim)

danawoodman commented 9 years ago

Is there a chance this will be resolved soon?

millermedeiros commented 9 years ago

@danawoodman this should take a considerable amount of work (maybe a few hours in the best case scenario?).. I'm currently busy with other projects and focusing mainly in making sure esformatter works well with valid JavaScript input (and adding support to ES6 features).. Pull requests would be highly appreciated.

one thing to be aware is that accorn_loose uses the indentation information to make a guess of block start/end, so it is not really that accurate... maybe there are other parsers that are better suited for our needs (we just need to figure out which parts of the code are invalid so that we can skip it).