chore: switch to true static attributes

[wraithgar]

now that we're off of node10 we can clean this up

[isaacs]

Probably not a concern in this case, but something to be aware of when switching from static get foo () { return 'bar' } to static foo = 'bar' is that it's no longer write-protected.

[wraithgar]

We can't move to this until we move onto @npmcli/eslint-config which is a larger task than just switching, because there are several bugs that were fixed there that aren't fixed here, such as line length enforcement being ignored in almost 250 places here.

[wraithgar]

Probably not a concern in this case, but something to be aware of when switching from static get foo () { return 'bar' } to static foo = 'bar' is that it's no longer write-protected.

Not in the constructor, but it's protected in the "blessed" api i.e. in the instantiated object.

https://github.com/npm/cli/blob/latest/lib/base-command.js#L12-L18

If someone requires the base class and overrides the constructor there that's ... on them?

[ljharb]

why do you need to wait for the eslint config? you should be able to set the parserOptions.ecmaVersion to 2022 in the meantime.

[wraithgar]

eslint@7 doesn't support it at all, and updating to 8 in this repo would have meant auditing the other eslint plugins and updating this local eslint config, something that had already been done in our linting repo. We already moved the linting today so it's just a matter of landing the breaking change to @npmcli/eslint-config

[wraithgar]

npm/eslint-config#10

[ljharb]

ah, true, you'd need to use @babel/eslint-parser with eslint 7.

[isaacs]

@wraithgar

Not in the constructor, but it's protected in the "blessed" api i.e. in the instantiated object.

Ah, ok, I'd missed that. Since we don't support loading npm programmatically any more in v8, I really can't see any problem. It's easy enough for us to just not do the wrong thing.