Support for "message" with "patterns" in no-restricted-imports

[mikeplis]

Creating a new request for a closed issue, as suggested here.

What rule do you want to change? no-restricted-imports

Does this change cause the rule to produce more or fewer warnings? Neither

How will the change be implemented? (New option, new default behavior, etc.)? Allow a new format for an existing option

Please provide some example code that this change will affect:

// I can currently customize the error message for restricted path imports like this
import * as moment from 'moment';
// But I can't customize the error message for restricted pattern imports like this
import { Button } from '../../framework/buttons';

What I'd like to do in my ESLint config:

{
  "rules": {
    "no-restricted-imports": ["error", {
      "paths": [{"name": "moment", "message": "Don't import moment"}],
      "patterns": [{"name": "**/framework/*", "message": "Only import from the root of /framework"}]
    }]
  }
}

What does the rule currently do for this code? I can't customize the error message for the restricted pattern import

What will the rule do after it's changed? It should allow me to customize the error message for the restricted pattern import

Are you willing to submit a pull request to implement this change? Sure, though I'd like to get some clarity on how difficult the "large option schema change" mentioned here would be.

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

[platinumazure]

Okay, we've had two team members review this and be in favor of the change but I think more folks can look at this.

I'll champion.

@eslint/eslint-team Can we review this please?

[kaicataldo]

@platinumazure Are you still championing this?

[martin-cech]

+1 for this to express interest :-)

[husseinbob]

Been smashing my head against a wall trying to find a way to do this. +1 interest

[nzakas]

Folks, no need to leave a comment to express interest. There’s definitely enough interest. What we need now is someone to figure out if it’s possible to create a rule schema to validate such options while maintaining backwards compatibility.

[platinumazure]

As I'm no longer a team member, I have removed my assignment and will not/cannot champion this rule. Would anyone else on the team like to champion this and drive this to completion?

[mdjermanovic]

What I'd like to do in my ESLint config:

{
  "rules": {
    "no-restricted-imports": ["error", {
      "paths": [{"name": "moment", "message": "Don't import moment"}],
      "patterns": [{"name": "**/framework/*", "message": "Only import from the root of /framework"}]
    }]
  }
}

An issue with this model might be that patterns can be related, as noted in this comment by @platinumazure.

The actual implementation treats "patterns" array as lines in .gitignore:

/* eslint no-restricted-imports:["error", {
    patterns:["foo/*", "!foo/good"]
}]*/

import bad from "foo/bad"; // error
import good from "foo/good"; // ok

Technically, "foo/good" is allowed because ["foo/*", "!foo/good"] as a whole doesn't match "foo/good" (positions in array also matter).

Schema proposed in #9846 covers this.

An alternative with the path/patterns object could be something like:

{
    "rules": {
        "no-restricted-imports": ["error", {
            "paths": [{
                "name": "moment", 
                "message": "Don't import moment"
            }],
            "patterns": [{
                "group": ["import1/private/*"], 
                "message": "Do not use any modules in import1/private"
            }, {
                "group": ["import2/*", "!import2/good"], 
                "message": "Do not use any modules in import2 except import2/good"
            }]
        }]
    }
}

"patterns" can be either:

• Flat list of strings. It would work the same as it works now.
• List of { group, message } objects.
  • group is a mandatory array of strings with at least 1 element.
  • message is optional.

Each group is a test for itself. If it matches, the import is restricted.

To avoid any confusion about the behavior of string elements in a configuration with groups (flat list of strings basically represents a group), I think that a mix of strings and objects in the "patterns" array should not be allowed: all patterns must be in group arrays.

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

[mdjermanovic]

I'll champion this.

[osdiab]

I am also interested in this happening - how can I help?

[mysticatea]

I'm wondering if we can simplify the options of the rule, similar to node/no-restricted-import.

[nzakas]

@mdjermanovic @mysticatea how should we proceed here?

[GiancarlosIO]

+1 🙏

[mdjermanovic]

If we are writing a new rule, then I think we should definitely choose one of the schemas proposed in this comment by @mysticatea.

But, since we already have the rule with defined schema, I'd vote for this solution, as it looks like a minimal addition to the existing schema and the logic that handles configuration.

[nzakas]

That sounds reasonable. Is the next step to produce an RFC? (This issue is flagged as needing a design, so double checking.)

[mdjermanovic]

That sounds reasonable. Is the next step to produce an RFC? (This issue is flagged as needing a design, so double checking.)

If we all agree on this schema, then I think an RFC wouldn't be necessary, as it's a small backwards-compatible addition.

If that schema doesn't look good, and/or we'd prefer to redesign the rule instead, then it would be probably better to go through the RFC process.

[nzakas]

Works for me. If no one else objects, let’s move forward with that.

[GiancarlosIO]

😢

[nzakas]

Folks, let’s keep the discussion professional, please. Sarcasm isn’t helpful.

In case it wasn’t clear, this issue has been accepted and is available for anyone to implement. This schema is the agreed-upon approach. We are looking for a community member to implement this as we are busy preparing ESLint for v8.0.0.

[lexholden]

I needed this for a big project, so made it as a custom rule locally as per to the defined schema and opened the above PR for feedback. #14580

Happy to put a bit of time into getting it mergeable if there's any change suggestions.