- Brandon Mills (@btmills) - TSC
- Milos Djermanovic (@mdjermanovic) - TSC
- Nicholas C. Zakas (@nzakas) - TSC
@nzakas moderated, and @btmills took notes.
TSC Summary: This PR seeks to add suggestions to no-misleading-character-class, specifically adding the “u” flag if it would result in a valid regular expression. Both nzakas and btmills have approved the PR, mdjermanovic has concerns about the side effects of the suggestions. We do allow side effects in suggestions in core rules.
TSC Question: Do we want to change our expectations around suggestions? (https://eslint.org/docs/developer-guide/working-with-rules#providing-suggestions) Can we merge this?
- @mdjermanovic views side effects as behavior changes unrelated to the reported problem.
no-useless-escapesuggesting changing/\a/to/\\a/would not be a side effect, but adding theuflag can change behavior unrelated to the misleading character class. - Digging into the semantic distinction, @nzkas asks if we agree that suggestions may change behavior. 👍 from @btmills and @mdjermanovic.
- @nzakas asks if we agree that changes narrowly focused to the problem, like changing
==to===, are okay. 👍 from @btmills and @mdjermanovic. - @mdjermanovic views the
==to===change as a "direct effect", whereas adding theuflag could have indirect side effects even if it's probably the best suggestion. A note in the message could help. - This is the first time we've encountered this nuance between direct and indirect behavioral changes as a team, and @nzakas would like to find a scalable solution so that we communicate to users appropriately.
- Right now, each rule documentation page with a suggestion has a lightbulb and the text "Some problems reported by this rule are manually fixable by editor suggestions." @nzakas proposes changing that to "Some problems reported by this rule may be fixable by editor suggestions. (Warning)" and linking "Warning" to a page that describes the potential pitfalls. 👍 from @mdjermanovic and @btmills.
- @btmills will open an issue on the website repository to make that change.
- @nzakas asks if we should merge the PR as-is or add alternate, more narrowly focused suggestions.
- @mdjermanovic is fine with merging the
uflag suggestion and thinking about other suggestions later. A few cases where the suggestion causes syntax errors will need to be fixed first. 👍 from @btmills and @nzakas.
Resolution: The current suggestions in the PR are fine to merge once syntax errors are fixed.
- Blog images are done, Sara is almost done with the blog section, and it looks fantastic with the images in place.
- We'll need to update frontmatter for all of our blog posts, and @nzakas opened a tracking issue.
- The donate and sponsor pages are done.
- The branding page and adding blog post syntax highlighting are in progress.
- The team page is finished, and team members can add Twitter usernames, website links, and descriptions to GitHub profiles that the page will pull from.
- The language picker, dark/light theme switcher and homepage animation are the major remaining pieces.
- Once that's done, we can share publicly and start gathering feedback.
- Sara will start on the docs site in the same repository initially to reuse components, and then we'll split it up at the end once we figure out the right way to reuse components across the marketing and docs sites.
- Red Hat donated $3,000 to ESLint, and @nzakas asks for retweets.
- @nzakas figures it was related to his podcast interview or Log4j.
- In January, @nzakas plans to put together an annual report showing the money we took in and how it was spent.
- @mdjermanovic volunteers for the release.
eslintis the only package that needs to be released.- As an FYI, @nzakas did a release of
@eslint/create-config, so that feature should be able to move forward, but not as part of the December 17th release.
Resolution: @mdjermanovic will release eslint.