Linting is failing because of the eslint rules conflicting with prettier output. Maybe it's a good idea to disable code formatting rules at all because we're forcing prettier formatting so after all there is no need to check them by eslint.

The eslint + prettier setup is there to ensure properly formatted code is committed to master. Looking at the eslint errors they are legit. Strings must use double quotes, this is default prettier setup. The project uses mostly default prettier style + trailing commas.

Wasn't it agreed that no string access and declaration would be allowed to avoid confusion?

But prettier soubleQuote is not always double quote but prefer double quote. https://prettier.io/docs/en/options.html#quotes

Using prettier in validation step ensures us that code formatting is correct so having eslint for that is unneccessary. In situations like this there is no way to have eslint and prettier pass because code is properly formated after prettier pass.

I see what you mean now. Yeah, our eslint-rule for quotes is misconfigured https://eslint.org/docs/rules/quotes#avoidescape we should have had an avoidEscape option enabled.

My primary concern was that it would be difficult to track down what is wrong with the source if there is only prettier validation as it'll simply point a file should be prettified but not which line/why it's failing. We could discuss disabling formatting rules, even though wouldn't really buy us anything.

For the errors you're getting, just edit the quote rule as it's misconfigured.

Coverage decreased (-0.2%) to 95.684% when pulling 8cf9fef on Baransu:dot-operator into ded8c9a on ballercat:master.

Waiting for review and initial feedback so I can improve things and convert examples/documentation.

My initial feedback is similar to the original PR.

Since the . dot operator is already a binary operator handled by the parser. Generating a node with two params for us for pretty much free:

[
  targetNode,
  parameterNode
]

All we should need to do is to map the params to something array subscript can consume. Which is a identifierNode.stringLiternalNode. Check this part of the operator parser logic

I don't really see a reason for us to keep track of the tokens in expression to figure out if it's an access operator or not.

I gave updating this branch a shot, but it's way out of date by this point. It's been a while since any updates, so I think I'm going to consider this PR abandoned and implement the dot operator a bit differently. At this point it's a bit of a blocker for some other features.

Fantastic. I was able to necromance the branch!

I hope you see why I went in a different direction. The changes to AST generators and validation made this feature a 3 line change.

Thanks for the help!