Add wildcard support to new-cap: capIsNewExceptions

[SimonSchick]

In some cases it would be nice to be able to specify to ignore a whole library for instance.

I ran into this problem when using sequelize types.

eg.

        type: {
            type: Sequelize.ENUM('something'), // <- error here
            allowNull: false,
        },

[eslintbot]

@SimonSchick Thanks for the issue! If you're reporting a bug, please be sure to include:

1. The version of ESLint you are using (run eslint -v)
2. What you did (the source code and ESLint configuration)
3. The actual ESLint output complete with numbers
4. What you expected to happen instead

Requesting a new rule? Please see Proposing a New Rule for instructions.

[nzakas]

There's not enough information here to know how to respond. Please either add more details to the problem you're reporting or more details to the proposal you're making.

[eslintbot]

Hi @SimonSchick, thanks for the issue. It looks like there's not enough information for us to know how to help you. If you're reporting a bug, please be sure to include:

1. The version of ESLint you are using (run eslint -v)
2. What you did (the source code and ESLint configuration)
3. The actual ESLint output complete with numbers
4. What you expected to happen instead

Requesting a new rule? Please see Proposing a New Rule for instructions.

If it's something else, please just provide as much additional information as possible. Thanks!

[SimonSchick]

Sorry, I wrote this in a hurry.

What I want to request is something like this:

/*eslint new-cap: [2, {"capIsNewExceptions": ["someLibraryWithUppercaseFunctions.*"]}]*/

So you don't have to whitelist all function separately.

[thedark1337]

I also run into this issue whilst using Sequelize with the rule.

In my .eslintrc.json I have to list specifically the items I want to whitelist. Such as

        "new-cap": [2, {
            "capIsNewExceptions": [
                "dataTypes.ENUM",
                "dataTypes.INTEGER",
                "dataTypes.ARRAY",
                "dataTypes.STRING"
            ]
        }]

I think it would be much better if wildcard support was added so it could turn into something like:

        "new-cap": [2, {
            "capIsNewExceptions": [
                "dataTypes.*"
            ]
        }]

[nzakas]

Seems reasonable. We would need to stick to just * representing a wildcard, but that's feasible. @SimonSchick @thedark1337 can one of you submit a pull request?

[SimonSchick]

I might, just a little low on time right now.

Is there any simple pattern matching utility included in the code base?

[thedark1337]

I might be able to. I think using glob would help with this (which is included in ESLint) , I'll take a look and see

[SimonSchick]

I think minimatch is ok since it's already a sub dependency via glob.

[thedark1337]

imo using a dependency is better than relying on its sub. I'll start working on it as soon as I get the time 👍 , actually wait, does glob even work for this case? Maybe just using a regex would work better?

[nzakas]

You just need to create a regex. Replace * with .* and escape the rest.

[thedark1337]

Sorry, @SimonSchick are you able to work on this? I haven't started yet on adding it in.

[diki]

I sent a pull request

#5484

[nzakas]

On the PR, a proposal was made for having full regular expression support and using a different option newIsCapWildcardExceptions.

I'm not sure I like the additional complexity, wheras the initial proposal was fairly simple. What do others think?

[ljharb]

My concern is overloading "a string property name" with "also maybe a wildcard" - it feels very much like repeating some of the language mistakes where it takes both a string and a regex.

Note that Foo.* alone would be not so bad, since that couldn't conflict with any property name, but if Foo* is allowed, I think it'd need to be a separate option.

[BYK]

I'm +1 for a separate name with RegEx support. We support regexes for identifier names in other places too.

[diki]

I think adding "Immutable.*" to existing options kind of violates plugin schema as it looks like regex, also that may create an impression like i can put any regex here.

[nzakas]

So what are we proposing here? capIsNewExceptionPatterns and newIsCapExceptionPatterns that are both arrays of regular expressions?

[BYK]

So what are we proposing here? capIsNewExceptionPatterns and newIsCapExceptionPatterns that are both arrays of regular expressions?

Almost that but not sure if they should be array. I think we can cover all cases with a single RegExp. If we have multiple patterns, we can always combine them using | right?

[ljharb]

I think either an array or a single pattern would work well - an array has the advantage that it's harder to cause a bug in the regex when adding or removing a pattern tho.

[BYK]

@ljharb supporting an array of regexes would be harder and less performant I think, that's why I resist a bit.

[ljharb]

Why would an array of strings that's .forEach'd be any harder than a single string?

[ljharb]

As for performance, certainly internally it could be concat'd to a single pipe-delimited string in the array case.

[BYK]

That would work. Still unsure. Gonna defer to @eslint/eslint-team

[nzakas]

Looks like we use one string for the id-match rule, so we should probably follow that convention.

[ljharb]

consistency wins, fair enough

[annie]

i can continue work on this since that PR was never merged!