Difference from standard

[ghost]

https://gist.github.com/johnmuhl/4592c57c0b1c85e5b4c8f035c3ecf6eb

The configuration-original.js file is generated by the rails/webpacker gem; configuration.js is the result of running prettifier-standard. standard-out.sh shows the offending code; i.e.

// Expected "[" and "]" to be on the same line
const paths = safeLoad(readFileSync(join(configPath, 'paths.yml'), 'utf8'))[
  env.NODE_ENV
]

Standard 10.x and 9.x show the same error.

[capaj]

I have the same behaviour:

[sheerun]

I think it is a bug on standard.js side, as whitespace makes sense there if we want to maintain line-length limit. I'd prefer to be more compatible with prettier than standard on this matter.

I'd suggest raising this issue (or sending a PR) at https://github.com/feross/eslint-config-standard

[sheerun]

OR you could argue this should be changed at https://github.com/prettier/prettier

[indiesquidge]

This brings up a wider question to me: does this package provide anything more for me than just using prettier like this?

prettier --write **/*.js && standard --fix **/*.js

I know it was mentioned briefly in the prettier library, but I'm just wondering why I would use prettier-standard over the one-liner above.

It seems like this library is actually not all that related to standard, since it doesn't use standard for formatting, and allows for rules to be overridden, which goes directly against the philosophy of standard to "just pick something".

I'm also concerned with prettier-standard's divergence from or outrunning of standard's rules, including things like enforcing "object-curly-spacing", even though this is still in discussion in the actual standard library. (I'm actually confused where the base-level ESLint rules are defined for this package, as there is no .eslintrc or eslintConfig property in the package.json.)

I'm just afraid that if I use this, harmony between the prettier-standard and standard will split over time, causing inconsistencies in my codebase. (It also feels somewhat misleading calling this prettier-standard when it is closer to just prettier-eslint.)

[sheerun]

standard is a linter and prettier-standard is a formatter, you won't get any errors to fix manually when using it. This is the difference from the snippet you provided above.

By "doesn't use standard for formatting" I just meant the standard cli command itself, not the standard eslint rules. Specifically prettier-standard uses internallyprettier-eslint.

My goal is to make prettier-standard respect most of formatting rules from standard. prettier-standardsupports arbitrary rules in .eslintrc so you can freely override anything. I think allowing developers to change things they don't like is more important than following the "philosophy".

object-curly-spacing is one thing you seem to not like, so you can configure it in .eslintrc. As for the divergence from standard, I'd like to avoid it if reasonable, so feel free to open an issue.

Base formatting rules are minimal and currently defined here:
https://github.com/sheerun/prettier-standard/blob/master/src/format-files.js#L68-L78

[ghost]

I think it is a bug on standard.js side, as whitespace makes sense there if we want to maintain line-length limit.

Standard does not enforce line length limits. To impose them here seems counter-intuitive.

I'd prefer to be more compatible with prettier than standard on this matter.

Thanks for clarifying your preference; for now I'll stick with standard Standard. I'm fine with this issue being closed unless you'd like to keep it open for others to have a broader discussion.

[indiesquidge]

standard is a linter and prettier-standard is a formatter

Right, but the snippet I posted included prettier, which is the formatter at the core of this library. I was asking what prettier-standard provides me as a library over just using prettier and standard in the one-liner I mentioned.

prettier-standard supports arbitrary rules in .eslintrc so you can freely override anything. I think allowing developers to change things they don't like is more important than following the "philosophy".

I generally agree that allowing for configuration of tools is valuable for developers, and that is exactly what ESLint provides. But Standard was built explicitly to avoid manual configuration and bikeshedding.

object-curly-spacing is one thing you seem to not like

It's not that I don't like the use of the object-curly-spacing rule here, it's that it isn't yet decided in Standard itself. There are plenty of other things I disagree with that Standard does (e.g. single-quotes in JSX, space after function name, etc.), but the whole point of me choosing Standard was to let go of my arbitrarily dogmatic opinions and let the library just make the decision for me, the benefit being zero configuration.

I don't want to have to maintain a .eslintrc, or update and change random rules over time. I have no problem delegating this to a team of people that will provide me a library of syntactic standards—even if I disagree with a choice they made. I will grow used to the rules that I initially disagree with, and in the end, all I care about in this context is style consistency.

Correct me if I'm wrong, but this library seems to conflict with that idea. It contains deviations from Standard, allows for rule changing and extension, and I'm not entirely sure what it provides someone over just using prettier and standard together.

[indiesquidge]

I want to make it clear that I am not trying to attack this library—I think it's awesome that it was created. I'm just trying to understand it.

I love the concepts of prettier, and I love the concepts of standard, and marrying them together seems like quite an awesome style and format standardization. It both removes the energy it takes me to both come up with my own style and format configurations, and the energy it takes for me to convince others to use such configurations. Basically, my team can rest assured that our code will be syntactically consistent and clean without having to install a bunch of things on different IDEs, waste time bikeshedding over indentation or quote preferences, or remain vigilant about our writing style. Using these two tools guarantees coherence with minimal cognitive effort.

But I am confused how this library gets me there. I would like to understand it better.

[sheerun]

@indiesquidge I think as a compromise we could introduce --strict flag, so 100% of standard rules are enforced, even these that don't make sense to me in light of prettier formatting

I'll accept the PR if anyone sends it

[sheerun]

Upon further requests I've decided to add all fixable rules from standard. This behavior is releasd in prettier-standard 6.0.0. Please not that the rule that is the subject of this issue is not fixable. This might be somehow solved in the future by #17