prettier-standard --check

rstacruz commented 7 years ago

It'd be nice to be able to check if files are properly formatted so we can use prettier-standard for lint tests, as well.

sheerun commented 7 years ago

would you like to contribute it?

tkurki commented 7 years ago

I would like to have my CI build fail if there are files not prettier-standard formatted, but I'm not sure how to go about it.

It looks to me that the easiest way would be to add a --failOnChanged flag that would cause the exit status to be 2 (1 signals failure for stdin formatting currently) if some files were actually formatted or stdin format output is different from input.

I imagine this would be different from --check, which I'd expect to not do anything, just check.

tkurki commented 7 years ago

Opened #24

fotanus commented 7 years ago

any idea on how to replicate prettier-standard eslint rules? I tried "extends": ["standard", "standard-react", "standard-jsx"] on .eslintrc.js, but it stills different, showing rules like no-undef, camelcase, react/prop-types and a lot more (827 problems).

On a higher level, if I could only dump pretty-standard configuration to an .eslintrc.js, do you think I could use eslintrc to lint it?

sheerun commented 7 years ago

prettier-standard uses fixable rules from standard config, but if you want to lint, you need to use all rules from standard, so you're right to use "extends": ["standard"]

fotanus commented 7 years ago

That is what I expected, but it don't works for me. Check this output:

root@blackpearl:/app# cat .eslintrc.js
module.exports = {
  "extends": "standard"
};
root@blackpearl:/app# npm run format

> @ format /app
> prettier-standard 'gulp/assets/javascripts/!(vendor)/**/*.js'

359 files were unchanged
root@blackpearl:/app# npm run lint 2>&1| grep error | wc -l
732

npm run lint runs eslint 'gulp/assets/javascripts/!(vendor)/**/*.js'.

Some of the errors that are complained when I run lint: no-unused-vars, no-undef, one-var. eqeqeq, camelcase, and others

sheerun commented 7 years ago

I'm not sure what you mean. no-unused-vars and others are not fixable rules, so prettier-standard is not able to automatically fix them. prettier-standard is a formatter, not a linter. It'll never output any linting errors. On the other hand eslint is a linter, so it outputs extra errorrs when you run it, it is expected. Please correct me if I misunderstood you.

fotanus commented 7 years ago

Thanks @sheerun, what you are talking makes sense. What I'm looking for right now seems to be a standard that only runs the format checker, not the full lint. So I actually only need the subset of standard rules that prettier-standard can actually fix. This is to avoid committing code without using prettier-standard first, and then modifying the code on the wrong commit. I can't introduce a complete lint tool check on my project deployment without a huge effort right now :-(

sheerun commented 7 years ago

@fotanus Here is the code to fetch prettier-standard rules:

https://github.com/sheerun/prettier-standard/blob/master/src/format-files.js#L60-L66

rjhilgefort commented 6 years ago

I made #59 recently not knowing that this existed. As I'm closing that issue in favor of this conversation, I just wanted to bump the thread as I think it would be a nice addition to the CLI interface.

rjhilgefort commented 6 years ago

Is there any workaround for this? I just want a way I can see the output of the linter without applying any fixes. If you point me to how I might be able to help make changes, I can give it a shot.

KidkArolis commented 6 years ago

@rjhilgefort the workaround im using is to install standard (version 11) and run standard to lint.

jasonkarns commented 5 years ago

For running on CI, letting prettier-standard actually format the files should be fine. And the exit status from prettier-standard lets you know if anything was formatted or not. So a successful exit is the same as a lint check. (And a nonzero exit indicates failure to pass the lint rules, where the git-diff indicates the necessary changes.)

I know this doesn't cover all use cases, but it's a workaround.

al2o3cr commented 5 years ago

@jasonkarns My team just ran into this - the exit code only gets set if formatting errors:

https://github.com/sheerun/prettier-standard/blob/master/src/format-files.js#L174

since files which were changed by formatting show up in successes, not failures. :(

KidkArolis commented 5 years ago

Feel free to remove this comment if you deem it to be off topic.. I always feel bad spamming with links to my repos..

For anyone following along, I've just published a package similar to this one, but with different tradeoffs: https://github.com/KidkArolis/pretty-standard.

I think prettier-standard is trying to preserve as much as possible of the standard's formatting (?) and it's trying to keep the cli interface close to that of prettier to make it a drop in replacement for prettier. It's useful if your project is already using standard, but you want to benefit from prettiers formatting capabilities without having to reformat the entire codebase. Correct me if I'm wrong here, @sheerun, if I misunderstood, then maybe the projects could be merged (?).

And pretty-standard is completely adopting prettier formatting, but it keeps all of the standard's non style linting rules. It also uses exactly the same cli interface as standard since it's based on standard-engine. It can both lint (pretty-standard) and format (pretty-standard --fix) your files.

So if you are a long time standard user, but you are looking to use prettiers formatting, this might be well suited for you. As a bonus you can even use .prettierrc to configure semicolons and quotes. (in fact, perhaps I should turn semis off by default since this is spiritually still standard ;))