Skip to content

fix(linter/plugins): replace Context class#15448

Merged
graphite-app[bot] merged 1 commit intomainfrom
11-07-fix_linter_plugins_replace_context_class
Nov 7, 2025
Merged

fix(linter/plugins): replace Context class#15448
graphite-app[bot] merged 1 commit intomainfrom
11-07-fix_linter_plugins_replace_context_class

Conversation

@overlookmotel
Copy link
Member

@overlookmotel overlookmotel commented Nov 7, 2025

Fix #15325.

Some ESLint rules create a wrapped copy of context, in order to patch report and pass that wrapped context object to another rule.

Some rules also rely on unspecified details of ESLint's implementation - that context is formed of 2 layers - top layer being RuleContext (id, report etc), and bottom layer being FileContext (filename, sourceText etc).

This usage was broken in our implementation because:

  1. We collapsed the 2 layers into 1.
  2. We used a Context class which stored its internal data in a private property. When context.report was called with a different this, it failed because the private property couldn't be accessed from an object which isn't an instance of the class.

Fix this problem by:

  1. Splitting Context into 2 layers like ESLint does.
  2. Not using classes or private properties.
  3. No methods/getters on context objects use this.

We now have:

  • Separate Context object per rule, containing properties related to the rule - a plain object which uses data from closure scope.
  • All rule Contexts inherit from the same singleton FILE_CONTEXT object, which provides getters for properties related to the file (same for all rules).

Tests adapted from #15326.

@github-actions github-actions bot added A-linter Area - Linter A-cli Area - CLI labels Nov 7, 2025
Copy link
Member Author

overlookmotel commented Nov 7, 2025


How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

  • 0-merge - adds this PR to the back of the merge queue
  • hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

@github-actions github-actions bot added the C-bug Category - Bug label Nov 7, 2025
@overlookmotel overlookmotel force-pushed the 11-07-fix_linter_plugins_replace_context_class branch 3 times, most recently from 80df3ec to 34fa651 Compare November 7, 2025 19:34
@overlookmotel overlookmotel marked this pull request as ready for review November 7, 2025 19:41
@overlookmotel overlookmotel self-assigned this Nov 7, 2025
@graphite-app graphite-app bot added the 0-merge Merge with Graphite Merge Queue label Nov 7, 2025
@graphite-app
Copy link
Contributor

graphite-app bot commented Nov 7, 2025

Merge activity

Fix #15325.

Some ESLint rules create a wrapped copy of `context`, in order to patch `report` and pass that wrapped context object to another rule.

Some rules also rely on unspecified details of ESLint's implementation - that `context` is formed of 2 layers - top layer being `RuleContext` (`id`, `report` etc), and bottom layer being `FileContext` (`filename`, `sourceText` etc).

This usage was broken in our implementation because:

1. We collapsed the 2 layers into 1.
2. We used a `Context` class which stored its internal data in a private property. When `context.report` was called with a different `this`, it failed because the private property couldn't be accessed from an object which isn't an instance of the class.

Fix this problem by:

1. Splitting `Context` into 2 layers like ESLint does.
2. Not using classes or private properties.
3. No methods/getters on context objects use `this`.

We now have:

* Separate `Context` object per rule, containing properties related to the rule - a plain object which uses data from closure scope.
* All rule `Context`s inherit from the same singleton `FILE_CONTEXT` object, which provides getters for properties related to the file (same for all rules).

Tests adapted from #15326.
@graphite-app graphite-app bot force-pushed the 11-07-refactor_linter_plugins_allow_accessing_context.id_in_createonce_ branch from aecb99c to 981cbc5 Compare November 7, 2025 19:44
@graphite-app graphite-app bot force-pushed the 11-07-fix_linter_plugins_replace_context_class branch from 34fa651 to a17ca32 Compare November 7, 2025 19:44
Base automatically changed from 11-07-refactor_linter_plugins_allow_accessing_context.id_in_createonce_ to main November 7, 2025 19:49
@graphite-app graphite-app bot removed the 0-merge Merge with Graphite Merge Queue label Nov 7, 2025
@graphite-app graphite-app bot merged commit a17ca32 into main Nov 7, 2025
20 checks passed
@graphite-app graphite-app bot deleted the 11-07-fix_linter_plugins_replace_context_class branch November 7, 2025 19:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-cli Area - CLI A-linter Area - Linter C-bug Category - Bug

Projects

None yet

Development

Successfully merging this pull request may close these issues.

JS Plugin Context Fails When Wrapped by External Plugins

1 participant