Unless the property name starts with an underscore, it is public. e.g. option.public, option._private So it is fine to access option.envVar.

Option was once a simple prototype class with all public properties. As new features were added and Option became more full-featured, the existing properties were preserved and the all-public pattern was continued. (Which does lead to some naming gymnastics to have both a property and a chaining setter.)

Unless the property name starts with an underscore, it is public. e.g. option.public, option._private So it is fine to access option.envVar.

It is not included in the typings, though, that's why I though it was private. Had to include it in the manually augmented module declaration along with Command._args because of that, see typings/commander.d.ts.

So do you think it should be added to the library's type declarations instead? Or can we also keep the change I suggest here? It's not always easy to remember which methods are setter-only and which can also be used as getters. Since there is no other meaningful interpretation for an Option.env() call with no arguments, I think it's okay if we keep it.

It is not included in the typings, though, that's why I though it was private.

Oops, that explains it, I had wondered why you hadn't just used the property!

So do you think it should be added to the library's type declarations instead?

Yes.

Or can we also keep the change I suggest here?

No. Option does not have any properties using the overloaded getter/setter pattern that is used quite a bit in Command.