Require Dot Notation Whenever Possible (dot-notation)

[julien-f]

Hey folks, what do you think about enabling the dot-notation rule?

[LinusU]

Generally positive, although I prefer using the [...] syntax when I have an object that's being used as a map. Now, in most modern code it would just be a Map instance and I wouldn't have this problem, but process.env comes to mind as somewhere were this would annoy me 🤔

[brodybits]

process.env comes to mind as somewhere were this would annoy me

Couldn’t we solve this by using a utility such as process-env to access the process.env members in a more flexible manner?

And couldn’t we use a similar wrapper solution in other cases someone needs […] member access?

I suspect minor efficiency cost should not prove to be a real issue given the improved readability in what seem to be exceptional cases.

[brodybits]

I would love to see this considered for Standard 14 (#1321).

[feross]

Modest ecosystem impact:

1..162
# tests 162
# pass  153
# fail  9

And they're all cases where dot notation would be a bit better. Since the rule is automatically fixable, I think this rule is a go for standard v14.

[feross]

After fixing repos I control, only 3 ecosystem repos fail.

• electron-spawn
• cliui
• application-config-path

[LinusU]

application-config-path is mine, I can fix it 👍

Funnily enough, it's exactly the case I described in my first comment and I actually think that the code will be a bit uglier 😬

Oh well, it's for the greater good 🚀

[feross]

Yeah, I actually agree with you. There's a small amount information that it feels like we're losing by always using dot notation. I noticed when I went through all the failing cases that I was using [] consistently in very specific situations like HTTP headers: res.headers['accept']. It's hard to put into words why this way feels better than dot notation for these certain cases, but it does.

Happy to reconsider this if we end up not liking it. But it's only required changes in a few places so I'm guessing it won't be that big of a deal :)

[LinusU]

[...] using the [...] syntax when I have an object that's being used as a map.

I think this is what does it for me. JavaScript doesn't really have a distinction between objects with specific properties, and just general maps/dictionaries (or, it has now Map, but many APIs came before that. You can see this clearly with TypeScript typing: process.env and res.headers are described as Record<string, ...> whereas objects have there specific keys described.

It would be awesome if it could somehow be enforced that process.env, req.headers, etc. always have [...] notation, but I think that's impossible 😄

[vweevers]

It's hard to put into words why this way feels better than dot notation for these certain cases, but it does.

In the case of headers, it feels better because you may have (or later add) headers that do require [...] syntax. For visual consistency, I prefer:

headers['user-agent'] = 'example'
headers['connection'] = 'keep-alive'
headers['accept-encoding'] = 'gzip, deflate, identity'

Over:

headers['user-agent'] = 'example'
headers.connection = 'keep-alive'
headers['accept-encoding'] = 'gzip, deflate, identity'

[mightyiam]

Perhaps I would write that way, as well, @vweevers. If you could contribute that as an option to the ESLint rule, then we'd have the option to consider it. I personally feel that it would be better to choose a not-always pleasing style over not choosing.