loucyx commented on PR #42184: URL: https://github.com/apache/airflow/pull/42184#issuecomment-2346630818
> What I mean is there are plenty of great open source projects that are doing this and will most likely do it better than us. I don't think I agree with this point, "better" would be really subjective. `xo` for example is a new script that we would have to run _instead_ of `eslint` which I would say is "not great", and you have to configure _it_ instead of ESLint, so we add another abstraction layer on top of ESLint. This line in their README is particularly "scary": > No decision-making. No `.eslintrc` to manage. It just works! Another popular one is [StandardJS](https://standardjs.com/) which makes similar promises and has a similar approach, but the config is even worse (for example no semicolons 😨). This packages are generally doing what we are doing here, but with opinions from someone else. So as I said before instead of "configuring" the linter, we end up "undoing" some configs to adapt them to us, and we still have to add some plugins on top to make it stricter for TS for example, which is generally not linted with best practices (saying this from my experience coding in TS since 2012). > I don't think we have specific requirements for airflow in terms of rules and all this is very opinionated. Being opinionated was the intention of the PR. On top of the regular "avoid foot guns" settings that every recommended configuration out there has, we have some to enforce readability, perf and type quality. This last one is the "strictest" of the bunch, and the one that might feel most different from other configurations, but will also make mistakes with types less common (forbidding `any`, avoiding `null`, forbidding `@ts-ignore` or `@ts-nocheck`, etc.). Popular settings generally try to adjust to non TypeScript developers, but being a TypeScript project is better to keep it strict. > I don't want to argue with the community about why we chose certain rules and why we did not, and how we integrate or not new rules. The argument then could be: Why did you used `xo` instead of `standardjs` for example. The community will always want to argue about style decisions. A good OS will use whatever style is standardized by the maintainers (every time I did OS contributions, I used the existing settings of the repo, even when almost everybody uses spaces instead of tabs). The difference being if you get a bunch of devs asking for a linting rule to change, is easy because you "own" the rules. > Taking an external set of rule that is standard in the industry seems easier to me. It's always easier to use code written by somebody else, yes, but things like "settings" (which is what ESLint rules are at the end of the day) should be something the maintainers themselves figure out. One common approach is to have the settings that you want to use in all your projects in a repo that you use as a scaffold (like I did while working at VMWare), or in a published package that you always include as a dependency (like I did with my `@lou.codes/configs`). All that being said, I'm happy to close the PR and let somebody else take a hit at figuring out what packages to use if this approach is not fit to folks in Airflow. I was asked to help with ESLint configuration, and this is the way I would do it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
