Default glob pattern like standard

[jasonkarns]

Would love to have prettier-standard use the same default glob pattern as standard itself:

by default standard will look for all files matching the patterns: **/.js, **/.jsx.

Certain paths (node_modules/, coverage/, vendor/, *.min.js, bundle.js, and files/folders that begin with . like .git/) are automatically ignored.
Paths in a project's root .gitignore file are also automatically ignored.

This would make running prettier-standard operate similar to standard (no options necessary, just normal conventional configuration by default)

[sheerun]

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.

[jasonkarns]

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)

[KidkArolis]

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.

[sheerun]

I'd rather prettier-standard operate more similar to prettier than standard

[KidkArolis]

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?

[sheerun]

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.

[KidkArolis]

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?

[sheerun]

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

[jasonkarns]

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.

👍