Suggested fixes to tsconfig, prettier config #156
Conversation
|
| "prettier": { | ||
| "proseWrap": "never" | ||
| }, |
There was a problem hiding this comment.
I'm in the "explicit configs camp" too 👍
.prettierrc.js
Outdated
| // Disabling search dirs and pointing directly at folder paths relative to this config file | ||
| // makes it easier for VSCode and WebStorm to find your plugins. |
There was a problem hiding this comment.
interesting - do you happen to have a link to some issues related to this? I'm just curious why the automatic plugin search tends to fail in those contexts
There was a problem hiding this comment.
Now that you've challenged me on it, I suspect that this is a defense mechanism for Rush in particular.
If you have a Lerna repo or something and you use a root-level package.json to keep your prettier devDependency, which lives in a root-level node_modules, then I think 99.9% of the time VSCode would "do the right thing".
But in a Rush repo, there is no root package or node modules, and plugins are kept in a special folder; VSCode typically can't find this folder unless you specify exactly where it is. I can test out simplifying this for this repo since it probably would work just fine.
There was a problem hiding this comment.
Ah, ye - this might makes sense in the context of Rush if the location of plugins etc is not standard. That being said, I prefer an explicit list of plugins rather than one based on auto-search.
Bump `@types/prettier`
Co-authored-by: Mateusz Burzyński <[email protected]>
|
^ One note -- I don't know if this is normal or not -- but it looks like this PR doesn't run CI checks at all (I'd feel a bit safer if it was actually running CI on a change like this). |
It's the whole mining prevention measure implemented by GitHub. For first-time contributors, the CI needs a maintainer's approval to run. I've approved this workflow - it should pass in a moment, I will land this and you won't have that problem again. |
SUMMARY
prettier-plugin-packagejsonprettier pluginuseUnknownInCatchVariablestypescript ruleDETAILS
I am open to pushback on this, but I think in general, using
package.jsonas an unstructured grab-bag is less discoverable than using tool-specific configuration files. So I was hoping to split out.prettierrc.jsinto its own file in the root.It would also be nice to add
prettier-plugin-packagejson-- it's very opinionated, as it wraps the opinionatedsort-package-jsonutility, but I've found it really nice to just give in and let VSCode auto-sort my whole packagejson every time I touch it.Last, I think we (and everyone else) should turn off
useUnknownInCatchVariables. Notably, even the TypeScript codebase itself turns this off -- the extra safety is not worth the hassle until TS starts offering some better assumptions (like at least being able to specifyerr: Error).