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 🤔

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.

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

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.

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

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

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 🚀

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 :)

[...] 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 😄

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'

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.

crap, now i must override this rule where i use closure compiler in advance mode

applies to when i want to keep something that should be exported as it's named

function displayNoteTitle(note) {
  alert(note['myTitle'])
}
// Store the function in a global property referenced by a string:
window['displayNoteTitle'] = displayNoteTitle

didn't like this addition.
ppl mostly use dot notation anyways? if not then they have a reason for it.

• consistency in stuff like headers and process.env
• closure compiler (also applies to Uglify, i think?)

Getting more and more tiered of linters that is strict about formatting. hence why i don't use them so much any longer.
all i want is a linter that can only spot errors, (telling me if i missed a variable declaration, if i reassigning const variables etc) not tell me how i should format my code or what i can or can't use 😞
can anyone recommend such linter to me?

Actually thinking of removing standard from my package now.
this was the straw that broke the camel's back...

@mightyiam I personally feel that it would be better to choose a not-always pleasing style over not choosing.

I generally feel this way too.

@jimmywarting ppl mostly use dot notation anyways? if not then they have a reason for it.

In general, this is probably true. The ecosystem impact of this change was low.

now i must override this rule where i use closure compiler in advance mode

I didn't realize that Closure Compiler was still a popular compiler. Does anyone else use Closure and is affected by this change?

all i want is a linter that can only spot errors

You could try doing using eslint-config-standard and eslint-config-prettier (which disables style-related rules)

I'll re-open this issue for a little while to give it visibility. If others have issues with this rule, we can reconsider it for the next minor version.