Rule Change: Add ability to ignore Undefined in Function Params

[elliot-huffman]

What rule do you want to change?

no-undefined

What change to do you want to make?

Generate fewer warnings

How do you think the change should be implemented?

A new option

Example code

const autopilotDevice: WindowsAutopilotDeviceIdentity[] = await this.GraphClient.iterateAllPages(await this.GraphClient.graphMethod('Get', '/deviceManagement/windowsAutopilotDeviceIdentities', undefined, `azureActiveDirectoryDeviceId eq '${ deviceId }'`) as PageCollection) as WindowsAutopilotDeviceIdentity[];

What does the rule currently do for this code?

This rule currently flags the undefined value manually put in the call signature of the graphMethod method to skip an optional parameter to be able to use a parameter that is further down the call signature.

What will the rule do after it's changed?

After changing the rule, the rule will have a new option that allows for silencing the use of undefined in call signatures. All other undefined usage detections should not be modified, just undefined usage in call signatures.

Participation

• I am willing to submit a pull request to implement this change.

Additional comments

As seen here:
https://stackoverflow.com/questions/8356227/skipping-optional-function-parameters-in-javascript

[mdjermanovic]

Hi @elliot-huffman, thanks for the issue!

The no-undefined rule disallows the use of undefined as an identifier. In other words, this rule disallows references to the global variable undefined, such as in the example you provided. It doesn't disallow generating undefined values. As stated in the documentation, for this purpose you can use void 0, and that will be valid code for this rule:

this.GraphClient.graphMethod('Get', '/deviceManagement/windowsAutopilotDeviceIdentities', void 0, `azureActiveDirectoryDeviceId eq '${ deviceId }'`)

I think that specifically allowing undefined identifiers in function calls wouldn't be in line with the purpose of this rule as there's no real difference between function calls and other contexts in this regard.

[elliot-huffman]

I missed that context for my usage, I am so sorry for the trouble. Good point. I completely agree on keeping the rule the same because of the ability to replace the value.

[elliot-huffman]

Opened Pull Request #16712 to update the docs to include my scenario because I know others may have a mindset like mine :-P