Atom-beautify: Beautify JS file doesn't match with ESLint "standard" option

Created on 6 Apr 2016  ·  25Comments  ·  Source: Glavin001/atom-beautify

Installed linter-eslint with eslint-plugin-standard. Works.

If I run "beautify". the code is changed to no longer be compliant with the linter rules. For example, eslint-standard expects a space between function and its (). I have tried adding "space_after_anon_function": true to my .jsbeautifyrc file. It still removes the space.

And way to adjust beautify to match the standard rules?

feature stale

Most helpful comment

Hello all,
I was able to get beautifying working based on my config in .eslintrc file.
install linter and linter-eslint.
⌘+⇧+P, then type fix and press enter on Linter Eslint: Fix File
As a test I changed my indent rule, say the lint errors, ran the command above, and it worked!

All 25 comments

+1 ...
This is important to me also. I had to disable the JS Beautify auto-save because it doesn't match the same rules as Standard. I am using Formatter now instead, which does match the Standard Linter. I would like to just use Beautify JS if you can make it match JS Standard rules. Thank you!

@emveeoh when you say you are using Formatter now do you mean this package: https://github.com/atom-community/formatter ?

If you would like further assistance with picking the appropriate options such that your code beautifies as desired, please provide us with your debug information as indicated in the steps found at https://github.com/Glavin001/atom-beautify/blob/master/ISSUE_TEMPLATE.md#debug
This will include a code sample and your current options that we can investigate.

For JavaScript, there are two three supported beautifiers: Pretty Diff and JS-Beautify, and also JSCS Fixer ( https://github.com/Glavin001/atom-beautify/pull/412 ).
I recommend that you ask on their respective repositories for help on which options they support that will give you the beautification you need.

A feature I am interested in support in future Atom-Beautify is importing from linting packages: https://github.com/Glavin001/atom-beautify/issues/286
And allowing Atom-Beautify to be much more flexible with how settings are imported: https://github.com/Glavin001/atom-beautify/issues/299

@Glavin001 Actually, the package that works well for me is atom-standard-formatter (https://github.com/stephenkubovic/atom-standard-formatter). It exactly matches linter-js-standard (https://github.com/ricardofbarros/linter-js-standard).

In a perfect world, re-formatting code with a beautification plugin should always match the linter rules for each of the respective languages. Otherwise, re-formatting will just write code that the linter complains about. They really need to work together. Formatter/Beautifier + Linter = happy. ;)

Indeed. I am now wrestling with why building my project that was formatted standard causes it to not run :-(

This perfect world should currently be possible so long as the beautifiers (JS-Beautify, Pretty Diff, JSCS Fixer, etc) support the necessary options and the user configures the beautifier (Atom-Beautify, etc) with those corresponding settings.
Assuming that the above is already true, I want to go a step further and _automatically_ detect the configuration from linters and import them into Atom-Beautify and translate those options over for the beautifiers. That is my perfect world.

Atom-Beautify could definitely support the same beautifiers as Atom-Standard-Formatter.
I see https://github.com/maxogden/standard-format which could be added as a beautifier to Atom-Beautify by creating a Pull Request following the instructions found at https://github.com/Glavin001/atom-beautify/blob/master/docs/add-languages-and-beautifiers.md#how-to-add-a-beautifier-for-a-language

Hopefully we can create this perfect world soon! :smiley:

Thanks for all the help @Glavin001 ! I'll grab that beautifier and give it a shot. BTW... the latest updates to the JS Beautify preferences is superb! It looks awesome!

Thanks. I use atom standard-format, but I used semistandard config. I found that standard removes semicolons which breaks all my code when it gets concatenated and minified.

The challenge with keeping a beautifier entirely in sync with a validator is that they are separate and unrelated projects each with different goals. Many of the features and requests that go into a beautifier might completely fail a lint process, but are highly demanded anyways. A beautifier that exists only to support the conventions expressed by a given lint configuration would be isolated from various edge cases and exotic concerns that make beautifiers popular in the first place.

It is unlikely beautifiers will support the full range of options that Linters will -- we cannot expect the beautifier to fix errors in code in the same way linters can detect them. However I am more so interested in finding options that belong to both, such as space_after_anon_function, and making sure the beautifier is configured to be in sync with the linter as much as possible.

how close we are to that perfect world?

Would it be possible to at least match the config files, or share them?

All, Pretty Diff has a styleguide option that basically bundles settings of other options to meet the needs of various style guides. If there is something lacking specifically please let us know and we can either patch it or direct issues to the respective beautifier.

I was thinking on a different strategy. Rather than configuring the beautifiers manually to match the linter, would it be possible to use e.g. an eslintrc file as the config file for the beautifier?

would it be possible to use e.g. an eslintrc file as the config file for the beautifier?

Absolutely. This would be in addition to .jsbeautifyrc support: https://github.com/Glavin001/atom-beautify/blob/master/src/beautifiers/index.coffee#L450
It would, of course, require additional instructions to transform from eslintrc format to the appropriate Atom-Beautify format.

I am seeing this issue also

If it could read an .eslintrc, wow that would be amazing.

This should actually be closed as a duplicate of https://github.com/Glavin001/atom-beautify/issues/286
However, since I closed https://github.com/Glavin001/atom-beautify/issues/286 as it moved to https://github.com/Unibeautify/unibeautify-options-importer/issues/2 I will leave this discussion open, since I want to ensure it is supported in v1.

Please 👍 the Issue description at the top of this page. Do not create new messages unless you would like to contribute or have other productive suggestions. Thank you!

Hello all,
I was able to get beautifying working based on my config in .eslintrc file.
install linter and linter-eslint.
⌘+⇧+P, then type fix and press enter on Linter Eslint: Fix File
As a test I changed my indent rule, say the lint errors, ran the command above, and it worked!

@miguel-orange that's great, so there was basically no need for beautify?

@ElegantSudo ,
I'm strictly using linter-eslint and have beautify disabled.

Muchas gracias miguel!!!

That is truly awesome

I found a helpful .jsbeautifyrc file that does the trick mostly for some things I wasn't able to fix with eslint. Just throw it in your root folder and give it a try.

https://gist.github.com/softwarespot/8a6d9bb6b848f3cc9824

Yes eslint is able to act as a formatter by automatically fixing the linting errors.

Although the problem is that even when disabling atom beautifier for javascript, but using eslint automatic fixing on save, parameters between the two seems to be shared somewhere and the file is formatted the beautifier way.

So beautifier seems to take precedence over eslint in the formatting process, even if javascript is disabled for the atom beautifier package... 😥

Is anyone using Beautify with VSCode? It also doesn't work fine with eslint rules.

https://standardjs.com/rules.html#javascript-standard-style

I don't think any of the beautifiers support this. The gotchas there are:

  • No semicolons. If a beautifier has a "fix" mode then semicolons are being inserted where appropriate and can just as easily be stripped. I don't think anybody offers this though, because it is a major violation of best practices. If your own code already works without semicolons then that is fine for you, but beautifiers manipulate code and in so doing there are so many combinations of benign changes that can unintentionally break code. While no semicolons is a minor risk to the code author (only after they have thoroughly tested their own code) beautifiers substantially compound that risk.
  • eqeqeq. This is something best left to the linters. Changing two character comparison to three character comparison can break code in ways unknown to beautifiers. The only way to known is to execute the code before and after beautifier and compare the changes in flow control.
  • Construct with no arguments must be invoked with parenthesis. I don't use any form of poly-instantiation (inheritance) ever, so I have no idea if forcing the parenthesis from a beautifier is risky or not.

For most of the rest of this I can create a new issue for Pretty Diff: https://github.com/prettydiff/prettydiff/issues/449

This issue has been automatically marked as stale because it has not had recent activity. If this is still an issue, please add a comment. It will be closed if no further activity occurs. Thank you for your contributions.

Was this page helpful?
0 / 5 - 0 ratings