Comments (15)
Or use https://eslint.style/
from standard.
What has happened that forces us to make a change?
ESLint 9 won't ship with style rules.
Why is that relevant?
Well, we want to support ESLint 9 eventually.
How can we support ESLint 9?
- Drop style formatting completely
- Follow the pattern that was used when ESLint dropped Node.js specific rules: Use a module that maintains those dropped rules separately
- Add a formatter so that standard doesn't just use ESLint it also starts to use eg Prettier or dprint
Which is the least disruptive solution?
Using the very same rules as now but from an imported package
Would it be better to use a formatter?
Maybe, but that feels like out of scope of what standard is. Eg many are using standard side by side with Prettier already.
from standard.
I think the ideal vision of the standard project was to stop arguing about linting and formatting in every project, to centralize that discussion, and then keep true to that decision for stability. Dropping formatting is, IMO, against that vision.
To circle it back to governance though, if there was governance in place we could have these discussions in an abstract way and then apply the "vision" to this issue. We don't have first principals documented, so we hare fighting out the "to format or not" discussion without agreement on the high level goals of the project. I would really like to formalize #1948 before any decisions like this are made personally.
from standard.
Maybe, but that feels like out of scope of what standard is. Eg many are using standard side by side with Prettier already.
Exactly! Many users are using Prettier and Standard side by side, so what's the point of including ESLint formatting rules, if it's indeed something that should be out of the scope of standard.
@theoludwig That would require an additional formatter for feature parity
I agree with @wesleytodd on this:
IMO one of the strengths of standard is that it works on the 90% of important formatting cases but does not have opinions on the rest
If you want 100% formatting – add a formatter (and likewise, if you want 100% linting, go with a custom extension of eslint-config-standard)
standard
is for describing and solving the 80-90% non-controversial stuff rather than prescribing solutions to the remainder 10-20%
from standard.
A couple of things:
- Getting a dprint config that aligns with standard’s current formatting can be a challenge – there likely will be formatting changes (I tried getting one that matches the internal Prettier + ESLint setup at @SocketDev but had to give up, took more time than I could justify)
- Having a native dependency (which I believe that dprint in all its shapes is) can cause disruptions for some platforms
- The eslint-plugin-dprint is yet another mysticatea abandoned module (the others that standard rely on me together with some others managed to rescue into the ESLint Community org), but seems like at least one maintained fork exists: https://eslint-plugin-dprint.ben12.eu/
from standard.
IMO one of the strengths of standard
is that it works on the 90% of important formatting cases but does not have opinions on the rest. This helps keep it palatable to a wider audience despite having some strong opinions, which is actually quite difficult to achieve. Abandoning that for a new tool seems like a lot of work, and has the chance to really break things for end users.
It is my opinion that we need a lot more analysis of the problem than this issue provides to make a good decision here, but that the default decisions should be to use the existing working setup as long as possible.
I don't have a strong opinion on dprint, but I am really uncomfortable choosing a native dep for this. Additionally it looks like that library is pretty generic, which likely means there will be a lot of work to use and might never really fully satisfy the needs.
from standard.
It's been working this far, step one would be to use eslint.style
Going down the route of dprint will be extremely hard without causing lots of disruption. Believe me, I have tried
from standard.
Yeah this is great! Honestly I feel like this is a great foundation for a conversation about how to move forward. Good problem statement and doesn't jump to a conclusion or a specific tool recommendation. @mightyiam, maybe we could reframe the discussion less around choosing a specific solution first and help fill in more details on what our options are and the pros/cons of them?
from standard.
Maybe, but that feels like out of scope of what standard is. Eg many are using standard side by side with Prettier already.
Exactly! Many users are using Prettier and Standard side by side, so what's the point of including ESLint formatting rules, if it's indeed something that should be out of the scope of standard.
from standard.
Would be best that Standard doesn't include any formatter, and only do the linting phase with ESLint.
from standard.
https://eslint.style is a fork of the style rules that are deprecated in ESLint and typescript-eslint.
I find this part from the deprecation blog post important:
Consistency issues. Because ESLint’s rules are designed to be atomic and not to have access to other rules, we would run into issues where it wasn’t possible to correctly fix an error because the information was in another rule. For example, if an autofix needs to add a new line of code, it would need to know how the file is indented in order to apply the correct fix. However, the indent rule controls indenting for ESLint, which meant that other rules needed to apply fixes without indentation and then trust that the indent rule would fix the indentation on a subsequent pass.
The architecture of ESLint isn't adequate for formatting.
from standard.
The disruption to the users amounts to having to accept the automatic formatting changes, I suppose?
from standard.
Why is reformatting our users' code such a big deal?
from standard.
Why is reformatting our users' code such a big deal?
I am not sure I understand this question. Can you provide more details on what you are trying to get at with this question?
from standard.
What has happened that forces us to make a change?
ESLint 9 won't ship with style rules.
I think ESLint 9 might be safe enough, according to the ESLint blog:
All of these rules will be deprecated as of the next release, but will not be removed until at least ESLint v10.0.0 (if not later).
from standard.
Related Issues (20)
- Formatting code will make it unreadable
- Expanding Rostislav and I's contribution, into core
- TS-Standart Changed My Code and Throwing Error
- Create a tutorial to use Standard together with Husky
- Eslint v9 support HOT 2
- Add a lock file HOT 3
- Could you please paste the result of the `npm ls eslint` command? HOT 1
- Remove the lock-threads workflow
- Comments bring issues/PRs onto the project board HOT 1
- tittle
- space-unary-ops errors on `new Class()` syntax HOT 4
- Maintenance & Governance of standard HOT 47
- inline link with @ in Super to have link inline or below not above HOT 1
- Tags isn't exported with Export .md or HTML HOT 1
- Ctrl+Shift+E to open/close tag page isn't working HOT 2
- `standard.lintFiles()` doesn't use `process.cwd()` HOT 5
- RFC: eslint-config-standard-with-typescript to depart from standard HOT 19
- Rule suggestion: no-constant-binary-expression
- Linting in precommit hooks says File not found
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 standard.