ESLint config: Print config and add tsdoc plugin #9740
Conversation
Per some feedback from @ChumpChief (#9489 (comment)), I'm consolidating the disparate configs into a single config in my next PR. So I would rather just print the default config, which is the one 99% of our packages use today, and then I'll update it with the results of the config changes in my next PR. |
This reverts commit 4eacb72.
|
@markfields I just pushed an update that includes changes to the readme, a second config for test files, and updates CI to fail the build if a config change is made without printing the config. Can you take a look? Thanks! |
| @@ -0,0 +1,6 @@ | |||
| /*! | |||
There was a problem hiding this comment.
do you need two dummy files for this? can both just point to the same dummy?
There was a problem hiding this comment.
ESLint overrides are based on glob paths -- so in order to get ESLint to correctly apply the test-only overrides, the file being linted has to match the test override globs. So it either has to be a .spec.ts file or in the /test/ path. I haven't come up with a better solution :(
| // Sort the JSON in-place | ||
| sortJson.overwrite(filePath, { indentSize: 4 }); | ||
| } | ||
| })(); |
There was a problem hiding this comment.
No .catch to log to console or anything?
| @@ -64,7 +64,7 @@ extends: | |||
| releaseBuildOverride: ${{ parameters.releaseBuildOverride }} | |||
| buildDirectory: common/build/eslint-config-fluid | |||
| tagName: eslint-config-fluid | |||
| taskBuild: false | |||
| taskBuild: build | |||
Part of #9501.
One question that comes up often when we make changes to our lint config is, "what changed?" This applies even when we don't make any changes other than upgrading deps, because the dependency upgrade might include a new rule.
ESLint provides a way to print the config that would apply to a file (
--print-config), so this PR uses this capability to print out the applied config as a JSON file. As we make changes to the config, we can print out the config again and get a diff to review as part of a PR -- just like we do with API reports for code changes.This PR also fixes a bug in the strict and recommended configs -- there was a missing dependency that needed to be added.