feat(linter): implement eslint-rule dot-notation

[pchorus]

Add ESLint rule dot-notation.

I took some inspiration and some code snippets from #9344.

I also implemented the fixer taking inspiration from https://github.com/oxc-project/oxc/blob/main/crates/oxc_minifier/src/peephole/convert_to_dotted_properties.rs as as suggested by @Boshen in #9344 and from the original ESLint implementation.

[graphite-app]

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.

[pchorus]

I needed to add parenthesis here. Otherwise, the parser doesn't accept it as I checked in the AST Explorer.

[graphite-app]

Bug: Incorrect validation of identifiers with Unicode characters

The is_valid_identifier function only validates ASCII characters, but JavaScript identifiers can include Unicode letters. This will incorrectly reject valid Unicode identifiers.

For example, these are valid in JavaScript but would be rejected:

foo["你好"]  // Chinese characters are valid identifiers
foo["café"]  // é is a valid identifier character

The function should use proper Unicode identifier validation according to the JavaScript specification, or leverage existing identifier validation utilities from the AST parser.

Spotted by Graphite Agent



Is this helpful? React 👍 or 👎 to let us know.

[graphite-app]

Critical: Potential panic on invalid user-provided regex

The code calls Regex::new(allow_pattern).unwrap() where allow_pattern comes from user configuration. If a user provides an invalid regex pattern, this will panic in production.

if let Some(allow_pattern) = &self.allow_pattern {
    if let Ok(regex) = Regex::new(allow_pattern) {
        if regex.is_match(&value) {
            return;
        }
    }
    // Or handle the error appropriately
}

Alternatively, validate and compile the regex once during configuration parsing in from_configuration() and store the compiled regex in the config struct.

Suggested change

	if Regex::new(allow_pattern).unwrap().is_match(&value) {
	if let Ok(regex) = Regex::new(allow_pattern) {
	if regex.is_match(&value) {

Spotted by Graphite Agent



Is this helpful? React 👍 or 👎 to let us know.

[codspeed-hq]

CodSpeed Performance Report

Merging #15957 will not alter performance

_{Comparing pchorus:feature/dot-notation (a6dcab3) with main (ef05957)}

Summary

✅ 4 untouched
⏩ 41 skipped¹

Footnotes

1. 41 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[pchorus]

@camc314 @connorshea Thank you for the support so far.
Is there anything missing from my side?
Do you need me to provide anything else to get this merged?
If so, I am happy to do so. Just let me know.

[connorshea]

are these results actually intended to work/do they work?

[connorshea]

We'll want to tweak this a bit to make sure the docs that get output are correct and have descriptions for these two config options:

Suggested change

	#[schemars(rename_all = "camelCase")]
	pub struct DotNotationConfig {
	allow_keywords: bool,
	allow_pattern: Option<Regex>,
	}
	#[serde(rename_all = "camelCase", default)]
	pub struct DotNotationConfig {
	/// TODO: Describe this option
	allow_keywords: bool,
	/// TODO: Describe this option
	#[serde(with = "Regex")]
	allow_pattern: Option<Regex>,
	}

The default thing just ensures that the JSON Schema emits a default value. #[serde(with = "Regex")] will ensure it gets a type value, otherwise I believe it just sets the type value to null and is not displayed. It may need to be schemars(with = "Regex") if serde doesn't work on that.

You can check what the generated docs look like by running cargo run -p website_linter rules --rule-docs target/rule-docs --git-ref $(git rev-parse HEAD) (or look at just website in the justfile and run that), and the generated docs for this rule will end up in target/rule-docs/eslint/dot-notation.md.

[connorshea]

Ah also you will need to rebase the branch to ensure that website command works, it was changed in the last few days