Difference from standard

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.

[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]

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.)