Use recast

[seflless]

I noticed on the Dailyjs coverage of this project that it mentions that format styling is lost when running fixmyjs on code. Have you considered using recast? I believe it maintains what styling it can while allowing you to work off the AST for transformations/fixing.
https://www.npmjs.org/package/recast

[albertjan]

See: https://github.com/jshint/fixmyjs/tree/recast

[goatslacker]

I'm thinking of merging recast into master, the only drawback right now is that we won't have ASI fixes.

[goatslacker]

RE: estools/escodegen/issues/203

cc @stereokai

I've been using recast quite a bit and I think it's good to go to master. I'll be using esformatter as well for formatting. The only thing holding this back at the moment is auto ASI fixes, which should probably be a feature of esformatter. If you'd like to contribute to a project I recommend adding more features to esformatter.

[stereokai]

@goatslacker where can I learn more about these auto ASI fixes?

[goatslacker]

I'm referring to having code that's missing semicolons "fixed", or alternatively, have semicolons removed from code that contains them.

[stereokai]

So to get things going, we need to make esformatter be able to perform these to actions?

[goatslacker]

Well something has to fix the semicolon issue, either here or esformatter. Probably here since semicolons are not a formatting issue.

[stereokai]

So... where can I start?

[goatslacker]

Start thinking of ideas :)

The current approach I'm using is to visit nodes based on types, this obviously doesn't work for ASI unless I have a global visitor. Which leads to the next issue: the problem/benefit of using recast is that it only rewrites the parts of the AST that have changed. So if you have semicolons missing everywhere they either won't be added in, or the entire file will be rewritten by recast, which may or may not be a problem if we're using esformatter afterwards.

With esformatter we wouldn't actually need recast, but I'd like esformatting to be optional so recast would most likely stay. I don't know, maybe I should just build this and feel it out.

[stereokai]

I'm listening; go on... ;)

[goatslacker]

That's all I have right now ^_^

[goatslacker]

Update: I created a v2.0 branch.

https://github.com/jshint/fixmyjs/tree/v2.0

Some breaking changes:

• I renamed es3 option to parseIntRadix because es3 makes no sense. I will most likely bring back es3 option as a catch all that does a few es3-related transforms (removing trailing commas, adding radix to parseint, etc)
• The config moved from .jshintconfig to package.json I feel like this is easier to manage and it would mean one less file in your root directory for those that aren't using jshint. It also removes a lot of the code from lib/cli.js where it has to look for all jshintconfig files. And finally, it centralizes some sane default options in fixmyjs' own package.json, at a glance you'll be able to tell what's enabled and disabled.
• I removed all falsy options. It's confusing to have false turn some options on while true turns others on. Now they're all truthy.
• Finally, I removed legacy mode. This is heartbreaking but it's something that needed to be done. Since 2.0 will be using recast + esformatter it will be performing transforms on what has changed rather than changing the entire file. AST transformations are safer than string replacements and allow us to write easier rules that are more maintainable. Plus it'll be easier to support ES6 in the very near future.

I plan to document all of this in Changelog as well as the README.

[stereokai]

Sorry for replying late. Looks like a great start!

I would like to comment that I am against moving the config from .jshint to package.json because it diverges from the standard (jshint - which is the fixmyjs "engine") as well as something that is a common practice and would probably be expected by developers.

The last point, removal of legacy mode and relying solely on AST is a blessing, and a step in the right direction. Well done!

Let's start testing!

[goatslacker]

Fair enough, I hate introducing breaking changes but jshint isn't the engine any more so it doesn't make sense to force people to use a .jshintrc file and adhere to jshint rules.

For example, if I add new rules in the future I'd have to make sure there is an existing rule on jshint and if there is ever a collision there would be an issue.

I feel this is a necessary evil.

[stereokai]

@goatslacker My bad! I thought jshint was doing the hard lifting here, a quick glance leaves no doubt of the contrary.

I don't see it as evil at all then, because the benefits listed above stand out now that we're disregarding the jshint "standard'.

[stereokai]

Just forked the grunt-fixmyjs fixed to the recast branch:

https://github.com/stereokai/grunt-fixmyjs

[stereokai]

@goatslacker Now using v2.0 in my environments and all seems fine (I'm git diffing the results on each modification).

Does fixmyjs accept options from grunt-fixmyjs? Otherwise that would be unfortunate.

EDIT: with grunt-fixmyjs, fixmyjs ignores any options in package.json, and demands a .jshintrc file to be present.

[goatslacker]

Yeah that needs to be amended if the tool would support v2