Prettier-eslint: Simplify the package

[zimme]

Now that prettier has a config file and an ignorefile maybe we could make this package "simpler" by not trying to infer configuration?

I personally would have no problem with having to setup a prettier config and a eslint config file in my projects and have this package just read those.

Any thoughts?

[kentcdodds]

I'm no longer using this project so I'm not going to make the deciding vote, but I'd say one of the speaks of this project is the inference, so I would recommend against a change like this.

[zimme]

I've been thinking about refactoring the code for this package and I've started to do that in some small ways, however I've also seen packages like prettier-tslint and prettier-stylelint getting released which got me thinking about taking this in a bit of a different direction.

Today if I wanted to use prettier-eslint for .js/.jsx files, prettier-tslint for .ts/.tsx files and prettier-stylelint for my .css/.scss/.less files, I'm pretty sure prettier will run 3 times on my files.

What I've been thinking about is a new project where we would consolidate all our efforts, and maybe call it prettier-lint/prettier-linter or some other "rad" name.

npm i -D @prettier-lint/eslint @prettier-lint/tslint @prettier-lint/stylelint

Where @prettier-lint/eslint would depend on @prettier-lint/core to provide an api to register itself with core and core would take care of running prettier and based on registered extensions running the linters.

By having @prettier-lint/core being used indirectly as a dependency of the other packages we should all be able to keep our original package names too, just with a major version bump.

However I do think that the cli's of our packages will need to restrict it's options unless we can find a good way to inherit and extend those so they get unified. However I'm in favor of just dropping cli options and relying on config files, as far as I can tell all linters have config file support including prettier.

I'm cc'ing some relevant people and I'm sorry, just unsubscribe if your not interested.
Kent, I know you don't use this any more but some thoughts/insights would be much appreciated.

Maybe we should talk with the maintainers or the editor plugins as their job would get easier with this as they would just have to integrate with the core package.

/cc @azz, @hugomrdias, @kentcdodds

[azz]

prettier-tslint has no CLI options :)

It would be interesting to have a package that sits on top of:

• prettier-tslint or tslint + tslint-plugin-prettier
• prettier-eslint or eslint + eslint-plugin-prettier
• prettier-stylelint
• prettylint e.g. for markdown files

That way you could lint all files with one command, and potentially unify the output. Currently prettier itself runs both eslint and prettylint.

[kentcdodds]

Sounds like a pretty good solution to have a prettier-plus package or something which could consolidate all the packages into a cohesive package where you can enable integrations easily. Good luck!

[zimme]

@azz I could see that work especially with prettylint in the picture.

With prettylint in the picture I don't even think we would have to use eslint-plugin-prettier/tslint-plugin-prettier as prettylint would pickup those linting errors/warnings.

I'm just wondering if such a package should provide all its dependencies or have them all as peer dependencies and apply the linters available. I'm thinking the latter.
@awesome-linter/cli
@awesome-linter/prettylint
@awesome-linter/eslint
@awesome-linter/tslint
@awesome-linter/stylelint
Where @awesome-linter/cli would have a dependency on @awesome-linter/core and @awesome-linter/<whatever>lint as peerDependencies.

I'll start hacking on a PoC.

[zimme]

I just got a hold of the @linter scope. 📦

[azz]

Did someone say monorepo? 😉

[zimme]

Maybe for core and cli, i'm thinking it would be "better" to have the linter-adapters in their own repos.

[zimme]

I've started hacking on this at https://github.com/linterjs. Destroy me with your feedback 😄
I'll start outlining my thinking a bit more as documentation/readme over the weekend, but I do believe there is enough code now to get a sense of where I'm going.

Let's move further discussions about this over to those repos.

[azz]

Looking good. Need to come up with a normalized output format similar to eslint results.

I made one for Prettier!
https://github.com/azz/linter-prettier

[azz]

Also opened a discussion here: https://github.com/linterjs/core/issues/1

[zimme]

With #145, some of my concerns have been addressed so I'm closing this.