Change scopes in comparison to language-babel

[Ben3eeE]

Requirements

• Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
• All new code requires tests to ensure against regressions

Description of the Change

• Add a scope for formal parameter identifiers that is not styled in one-syntax
• Add unquoted to member_expression > identifier
• Add component.jsx to jsx components
• Add spread scope to the spread operator
• Scope some variables as support.variable.dom

Benefits

Users of language-babel will see more familiar highlighting or can configure it to be more familiar and still get the benefits of tree-sitter parsers

Possible Drawbacks

• support.variable.dom has the variable class so these will be highlighted as red in one-syntax. This is what TextMate scoped them as except for console which was entity.name.other.console.js or something.

I am open to change the scope for support.variable.dom and move back window and document to be support.variable if someone has a better scope name.

Applicable Issues

Refs #625

/cc: @maxbrunsfeld @atomiks

[Ben3eeE]

Add unquoted to member_expression > identifier

Actually this change is wrong compared to how language-babel does it. It scopes a and b in:

let c = {a:1, b:2}

as string.unquoted.

While I added unquoted to a in:

c.a = 15;

[atomiks]

Nice! Any reason why the arrow function change isn't included in this PR?

i.e. both

const fn = () => {};

and

class X {
  fn = () => {};
}

fn should have function scope

[Arcanemagus]

Should performance be marked as this scope? As far as I know it's not part of the DOM, but I could quite easily be mistaken here.

console and navigator could also potentially be left out of here, but as they are accessible under the window object I can see leaving them here.

I'd suggest leaving performance as support.variable, but as the TextMate grammar currently marks it as support.variable.dom and it does call the main timestamp a DOMHighResTimeStamp I can definitely see leaving it there.

I just wanted to bring it up in case we were inheriting a bug from TextMate 😉, feel free to leave it there!

[maxbrunsfeld]

Maybe performance was previously grouped with window and document because it is a browser API (as opposed to something that's available in node and other non-web environments).

I don't have strong opinions either way.

[maxbrunsfeld]

Let's go with this. We can come back and tweak it further later.

[Ben3eeE]

@atomiks Arrow functions are left out because I can't find a good way to do it. Those would be better to tacle in a separate issue.