[Due for payment 2025-02-25] [HOLD for payment 2025-02-xx] Allow "private_" prefix lint rule for variable naming

[srikarparsi]

Problem

Our current lint does not allow private_isArchived as a variable name because the current naming conventions only allow for camelCase, UPPER_CASE, and PascalCase. This causes us to have to manually ignore eslint whenever we are using this variable.

Solution

Update our ESLint rules to allow for variables prefixed by private_. The expected behavior is that anything after the private_ prefix should be camelCase. A sample PR that starts on this is here.

Issue Owner

Current Issue Owner: @abekkala

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ZhenjaHorbach (External)

[melvin-bot]

Triggered auto assignment to @abekkala (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[srikarparsi]

Internal conversation about this here. cc @roryabraham and @mountiny

[Shahidullah-Muffakir]

Edited by proposal-police: This proposal was edited at 2025-01-06 17:50:54 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

The ESLint configuration doesn't allow variables prefixed with private_ (like private_isArchived), forcing manual ESLint ignores for these cases since naming conventions only permit camelCase, UPPER_CASE, and PascalCase.

What is the root cause of that problem?

Current @typescript-eslint/naming-convention rule configuration lacks support for variables with private_ prefix.

What changes do you think we should make in order to solve the problem?

Update the @typescript-eslint/naming-convention rule to allow private_ prefixed variables with camelCase after the prefix:
update the

App/.eslintrc.js

Lines 133 to 137 in 8381d8f

	'error',
	{
	selector: ['variable', 'property'],
	format: ['camelCase', 'UPPER_CASE', 'PascalCase'],
	},

as:

              'error',
      {
        "selector": ["variable", "property"],
        "format": ["camelCase", "UPPER_CASE", "PascalCase"],
        "filter": {
          "regex": "^private_[a-z][A-Za-z0-9]*$",
          "match": true
        }
      },

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

What alternative solutions did you explore? (Optional)

[ZhenjaHorbach]

@Shahidullah-Muffakir
Thanks for your proposal
But have you tested it?
As far as I can see, your solution does not work
Unlike, for example, the solution from this PR
Could you update your proposal, please ?

[nkdengineer]

Edited by proposal-police: This proposal was edited at 2025-01-06 18:55:11 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

Allow "private_" prefix lint rule for variable naming

What is the root cause of that problem?

We only allow variable names with camelCase, UPPER_CASE, and PascalCase

App/.eslintrc.js

Lines 133 to 137 in 8381d8f

	'error',
	{
	selector: ['variable', 'property'],
	format: ['camelCase', 'UPPER_CASE', 'PascalCase'],
	},

What changes do you think we should make in order to solve the problem?

we can update @typescript-eslint/naming-convention here to allow private_ prefixed variables

            {
                selector: ['variable', 'property'],
                format: ['camelCase', 'UPPER_CASE', 'PascalCase'],
                filter: {
                    regex: '^private_[a-z][a-zA-Z0-9]+$',
                    match: false,
                },
            },

We also need to remove some disable eslint // eslint-disable-next-line @typescript-eslint/naming-convention

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[ZhenjaHorbach]

@nkdengineer
Thanks for your proposal
But your solution is not exactly what is required
Since it allows to use any snake_case naming
And it does not matter what prefix we use
Could you update your proposal, please ?

[Shahidullah-Muffakir]

@ZhenjaHorbach
Thanks for reviewing the proposal! I’ve updated the proposal.
Edit: My solution is not working correctly, looking into it.