no-restricted-imports does not show which member is deprecated or allow for message customization per member

[RyanCCollins]

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

The DX of this rule does not indicate which member is deprecated when using importNames, nor does it allow message customization per member in the importNames list. I would like the rule to handle this to improve the developer experience and make it useful for deprecations across a distributed organization.

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

How will the change be implemented? (New option, new default behavior, etc.)?
There are a few options:

1. The configuration allows multiple paths with the same name so that you can have different custom messages for specific importName members.
2. The configuration allows a list of messages that map to the importNames.

Please provide some example code that this change will affect:

For #1 above:

    'no-restricted-imports': [2, {
      'paths': [
        {
          'name': '@someorg/api',
          'importNames': [
            'fetchThings',
          ],
          'message': 'fetchThings has been deprecated as of April 19, please use fetchWidgets instead.'
        },
        {
          'name': '@someorg/api',
          'importNames': [
            'postThings',
          ],
          'message': 'postThings has been deprecated as of April 19, please use getWidgets instead.'
        },
        {
          'name': '@someorg/api',
          'importNames': [
            'parseCSV',
          ],
          'message': 'parseCSV has been deprecated as of April 18 and will not be replaced.'
        },
      ],
    }],

For #2 above:

    'no-restricted-imports': [2, {
      'paths': [
        {
          'name': '@someorg/api',
          'importNames': [
            'fetchThings',
            'postThings',
            'parseCSV',
          ],
          'messages': [
            'fetchThings has been deprecated as of April 19, please use fetchWidgets instead.',
            'postThings has been deprecated as of April 19, please use getWidgets instead.',
            'parseCSV has been deprecated as of April 18 and will not be replaced.',
          ]
        },
      ],
    }],

What does the rule currently do for this code?
For #1, only the last path in the list works, the others are ignored.
For #2, it breaks because messages is not recognized.

What will the rule do after it's changed?
It will allow for specific messages per member so that the warning is specific to the member, providing better user/developer experience.

Are you willing to submit a pull request to implement this change?
I wish I was able to, but unfortunately don't have the bandwidth at the moment. We rely on this tool for work and would really appreciate this change being implemented. I will attempt it in a few months if not.

[RyanCCollins]

By the way, if I am misusing this rule and there is a way to do this currently, I would much appreciate some advice! Thank you!

[nzakas]

Have you checked the discussion on these issues?

#14220
#14274

[RyanCCollins]

Have you checked the discussion on these issues?

#14220

#14274

Awesome, the no-restricted-syntax looks like a good solution. Thank you @nzakas!

That said, I would still like to be on the record to say that I expected no-restricted-import to have a way to specify separate messages per member. Otherwise, there is no way the consumer would know which specific members are deprecated from a large module that has only a few members.

[nzakas]

Noted, given that it’s already tracked in another issue, I’m going to close this one.