jaredpalmer / tsdx

Zero-config CLI for TypeScript package development
https://tsdx.io
MIT License
11.2k stars 505 forks source link

How can I get rid of prettier completely? #1128

Closed ackvf closed 2 years ago

ackvf commented 2 years ago

Current Behavior

Working with prettier is PITA. I don't like how it formats my code.

Desired Behavior

I would like to get rid of it completely. What can I do about it?

Suggested Solution

Who does this impact? Who is this for?

It will only affect powerusers who like to control their configurations.

Describe alternatives you've considered

.prettierignore

Additional context

https://github.com/jaredpalmer/tsdx/issues/917 https://github.com/jaredpalmer/tsdx/issues/634

agilgur5 commented 2 years ago

Unfortunately there is no way of getting rid of it completely at this time, due to TSDX's current highly coupled nature (it's incredibly problematic; I didn't design it -- c.f. one of my early PRs #407). Some of the issues you've linked were methods of slowly decoupling TSDX.

What might interest you is disabling the Prettier rules from ESLint, which you can do with one-line in your ESLint config per https://github.com/jaredpalmer/tsdx/issues/498#issuecomment-583244717 You can't fully remove it right now, but you can disable it.

ackvf commented 2 years ago

Interesting, what does this rule do? It disables prettier checking within eslint, or does it disable prettier itself, so prettier does NO formatting at all?

agilgur5 commented 2 years ago

TSDX currently only has a tsdx lint command, so Prettier is only used within the context of ESLint (see the default config).

So disabling Prettier checks within ESLint means that tsdx lint will no longer report Prettier errors and tsdx lint --fix will no longer format with Prettier rules

ackvf commented 2 years ago

It's been few years since I was setting that up, I may need to refresh my knowledge.

I thought that it's just extending prettier rules, so that you don't get errors in IDE for prettier related issues. I was under the impression that prettier fixes everything regardless of any errors displayed in IDE.

Anyway I was just going through this https://prettier.io/docs/en/integrating-with-linters.html, so tsdx uses something like eslint-plugin-prettier and runs prettier within eslint only after eslint finds an error? And then, if eslint finds an error, it doesn't send prettier the whole document, but just that part of code, so prettier effectively doesn't do anything?

That's awesome. But I assume this rule 'prettier/prettier': 'off' only works for this particular setup, right? In setups where both eslint and prettier run separately, it won't care what eslint lists in eslint config...

Thanks!

PS: I managed to disable prettier with .prettierignore by adding all *.

agilgur5 commented 2 years ago

so tsdx uses something like eslint-plugin-prettier and runs prettier within eslint only

Yup exactly.

after eslint finds an error? And then, if eslint finds an error, it doesn't send prettier the whole document, but just that part of code, so prettier effectively doesn't do anything?

I don't totally know how eslint-plugin-prettier works under-the-hood, so can't answer that implementation detail question with confidence. But suffice to say, that's not TSDX implementation, but eslint-plugin-prettier implementation.

But I assume this rule 'prettier/prettier': 'off' only works for this particular setup, right?

Yea, it's turning off the ruleset that's associated with eslint-plugin-prettier. That works with TSDX because your config is (currently) merged with TSDX's. Normally your ESLint config would have to turn on the rules somewhere but because of how it's currently set-up it's done invisibly in a potentially unintuitive way. See also #634 , which you've already linked

PS: I managed to disable prettier with .prettierignore by adding all *.

That works too I suppose 👍

Closing this out as the symptoms have been resolved and the root cause already has a few issues open for it to decouple parts of TSDX