Feat/all-technologies-config #101
Conversation
| @@ -1,6 +1,6 @@ | |||
| 'use strict'; | |||
|
|
|||
| module.exports = { | |||
| export default { | |||
There was a problem hiding this comment.
turning these into ESM syntax
| import javascript from "./javascript.js"; | ||
|
|
||
| export default [ | ||
| ...javascript, |
There was a problem hiding this comment.
do we want to include the javascript rules here by default, or allow developers to mix in the inheritance themselves?
| import js from '@eslint/js'; | ||
|
|
||
| export default [ | ||
| js.configs.recommended, |
There was a problem hiding this comment.
should we bake these in these js.configs.recommended, defaults? or let developers choose if they want to include
| nodePlugin.configs['flat/recommended'], | ||
| ...javascript, | ||
| { | ||
| files: ['**/*.json'], |
There was a problem hiding this comment.
wondering if we should break these out into a separate json rulset, and if so, if we should include it in this ruleset definition or leave it separate for developers to mix in as they choose?
| 'yield-star-spacing': 'error', | ||
| }, | ||
| }]; | ||
| export { ember, javascript, node, typescript }; |
There was a problem hiding this comment.
we would need a major version release, as this breaks how its imported in existing versions
| @@ -2,10 +2,8 @@ | |||
| "name": "eslint-config-crowdstrike", | |||
| "version": "11.0.1", | |||
| "description": "ESLint config for CrowdStrike", | |||
| "main": "index.js", | |||
There was a problem hiding this comment.
changing this package to module. Would definitely need to be released as a major version as this is a breaking change
| @@ -33,13 +31,16 @@ | |||
| }, | |||
| "homepage": "https://github.com/CrowdStrike/eslint-config-crowdstrike#readme", | |||
| "dependencies": { | |||
| "@eslint/js": "^9.0.0" | |||
| "@eslint/js": "^9.10.0", | |||
There was a problem hiding this comment.
Open question is if we should keep this as a single bundle and assume the consuming project will treeshake the dependencies on build, or if we should have individual package.json's for each ruleset, and be a true monorepo
|
I def wanna release this as a beta/release-candidate first so i can test it in other repo's first |
| { | ||
| files: ["**/*.{js,mjs,cjs,jsx,gjs}", "tests/**/*.*ts"], | ||
| // These rules don't apply to JavaScript. And for tests they're annoying | ||
| // due to how much of "@open-wc/testing" is typed as `any` or inconsistently. |
There was a problem hiding this comment.
I wonder if we should remove the part about about the tests/**/*.*ts directory and@open-wc/testing comment here, since it is pretty specific to that one library.
I feel like in general we wouldn't want to disable typescriptEslint.configs.disableTypeChecked for anything inside of a tests/**/*.*ts directory. If those are also TS files, then it seems like something we should lint as typescript unless there's a good reason not to. Also different projects may have different a structure for where the tests could be.
| export default [ | ||
| ...javascript, | ||
| ...typescriptEslint.configs.recommendedTypeChecked, | ||
| ...typescriptEslint.configs.stylisticTypeChecked, |
There was a problem hiding this comment.
I'm not sure if all projects would want these rules from stylisticTypeChecked by default or not. I could imagine that some projects might use Prettier directly, or have some other specific ruleset for their formatting.
What do you think?
|
V2 can be separate package.json's / true monorepo |
We can make this repo the one stop shop for all crowdstrike configs.
noderuleset is taken from https://github.com/CrowdStrike/eslint-config-crowdstrike-node