Comments (9)
Isn't that pretty common across most unix tools? (that usage info is only printed when --help
is passed?)
Without dismissing the value of discoverability, the help output is only useful for people on their first-ever run; likely just poking around. Every invocation after that, they're intending to actually run the formatter. This should be optimized for the 90% use case (which is actually running the formatter), not the .1% use case of getting help. (Which is already conventionally available via --help
like every other *nix CLI)
standard
itself does this, and isn't this tool supposed to be part and parcel with standard? (not to mention, *nix convention)
from prettier-standard.
Yes, I'll close this issue. The problem is Unix tools don't change anything by default and prettier-standard would automatically format all .js files if I made this a default, which can be annoying.
The --lint
issue is already there: #17
from prettier-standard.
Unfortunately this would also make it harde to discover --help
panel that is displayed when prettier-standard is run without any arguments. As for ignores, they should be ignored now as well.
from prettier-standard.
Are you open for a PR on this? Would bring standard and prettier-standard much closer.
As a separate, but very much related suggestion/PR? Should this tool follow "standard" configuration specified in package.json? e.g. respect "ignore" config.
from prettier-standard.
I'd rather prettier-standard operate more similar to prettier than standard
from prettier-standard.
I have a lot of thoughts on this, I might try to compile them into a blog post..
It's an interesting one, I mean, I'm just after convenience and right now I find the current setup slightly inconvenient, but maybe it's just because of my workflow, maybe it works for others.
I'd rather prettier-standard operate more similar to prettier than standard
Thing is, if you use prettier-standard, you don't need prettier anymore. But you still need linting. So you have to use both prettier-standard and standard. But they both have different API and different configuration. Prettier itself doesn't have that problem, because people using prettier generally don't use standard, so the compatibility there is not important.
Arguably, they're just different tools (one's formatter, one's linter), so they don't have to work the same. I'm just trying to think of a best way to combine them (prettier and standard), which I thought this tool (prettier-standard) does, but really it's just a specific variant of prettier rather than combination.
Out of curiosity, when you use prettier-standard, do you also use standard? Or eslint? Or something else?
from prettier-standard.
I'm using prettier-standard and separately eslint with following config:
{
"extends": ["standard", "standard-react"],
"env": {
"jest": true
},
"rules": {
"indent": "off",
"react/prop-types": "off",
"no-eval": "off",
"react/jsx-indent": "off"
},
"globals": {
"drift": true,
"localStorage": true
},
"settings": {
"react": {
"version": "16.3"
}
},
"parser": "babel-eslint"
}
I think ideally prettier-standard would become a fork of prettier with less configuration flags and standard compatibility that is now being rejected from prettier: prettier/prettier#5723
Additionally it could have --lint
flag that would additionally pass code through eslint with standard configuration (with any whitespace rules disabled).
standard
itself unfortunately won't ever be compatible with prettier-standard
when it comes to whitepace formatting e.g. because how trenary expressions are indented (standard indents each level, and prettiers keeps everything at the same level). Standard has also some quirks to be fixed when it comes to jsx indentation and formatting.
from prettier-standard.
Yes, --lint
flag would actually mean prettier-standard
becomes a fully standalone tool that can both format and lint with zero config required (except for glob...)!
Should this issue be closed then (although I still agree with OP, default glob would be sweet, or at least configurable)? And --lint
issue be opened?
from prettier-standard.
I also have mixed opinions. I like both standard and prettier (and prettier-standard) because of the overarching philosophies to eliminate or reduce configuration, which eliminates bike-shedding. In general, I'm pro convention over configuration, so I very much appreciate standard's default CLI behavior.
As a standard user, I also rather expected prettier-standard to be philosophically in-line with standard and to be more convention driven.
However, I also see the argument that prettier-standard is really a replacement for prettier, and so it should be as near a drop-in replacement as possible. (And keeping a similar-behaving CLI reduces friction when/if people switch.)
And while most invocations of prettier-standard would be within a VC repository, thus making "oops" invocations revertible; I also appreciate the desire to not have "mutate files" be the default if ever invoked outside VC.
👍
from prettier-standard.
Related Issues (20)
- Issue with the parser argument HOT 3
- Extra semi-colon added before destructuring assignment HOT 3
- not catching no-implicit-any HOT 22
- lint by default HOT 8
- Can't resolve typescript type HOT 1
- Errors while linting TypeScript HOT 12
- ternary expression formatting raises an error in standard HOT 2
- Included packages? HOT 2
- there is a format question in typescript file HOT 1
- Allow overriding `parser` option in `.eslintrc`
- Error: "prettier/@typescript-eslint" has been merged into "prettier" in eslint-config-prettier 8.0.0 HOT 2
- Feature Request: loglevel output control
- Stuck saving with 'Format On Save' enabled HOT 1
- Error: You must provide patterns to match outside of git repository HOT 2
- is it possible upgrade to eslint 7?
- How do I send a custom CLI option to eslint?
- Dependency deprecation warning in Node 16+
- Security Vulnerabilities after including prettier standard
- Where I have to put .prettierrc for customization?
- This project is abandoned HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from prettier-standard.