-
-
Notifications
You must be signed in to change notification settings - Fork 726
Open
Labels
A-linter-pluginsArea - Linter JS pluginsArea - Linter JS plugins
Milestone
Description
A short "shopping list" of potential changes/optimizations to JS linter plugins.
The first is a potential edge case bug. The rest are not urgent or important, but I just wanted to note them down somewhere.
-
ExternalPluginStoreshould not containplugin_names.- Plugin name to plugin ID should be resolved on a per-config basis
(because 2 plugins can have same name but be different plugins). - Configs should store plugin IDs.
- Plugin name to plugin ID should be resolved on a per-config basis
- Remove
registered_plugin_pathsfromExternalPluginStore. It's only needed while building configs, but never used again after that stage. -
external_rules_for_overrideinOxlintRules::override_rulescould be aFixedBitSet?
There probably aren't that many external rules, soFxHashMap<ExternalRuleId, AllowWarnDeny>is inefficient. - Use only 1
Resolverfor all nested configs - creating aResolveris not cheap, and if there's only one, they'll all use the same cache. - When JS plugin creates an error, code to get severity for rule is not optimal:
- It has to search through
external_rulesto find the entry withRuleId - refactor(napi/oxlint): diagnostics communicate which rule via rule index, not rule ID #12482
- It has to search through
- JS class for
Context. refactor(napi/oxlint): introduceContextclass #12440 - Recycle
Contextobjects. perf(napi/oxlint): singleContextobject per rule #12475 - Add
idproperty (rule name) toContext. feat(napi/oxlint): addidtoContext#12480 - Improve perf of merging multiple visitors when many rules. perf(napi/oxlint): optimize compiling visitor #12472
Metadata
Metadata
Assignees
Labels
A-linter-pluginsArea - Linter JS pluginsArea - Linter JS plugins