Bug: `no-restricted-imports` doesn't distinguish between package names that have a substring as a name about eslint

[mdjermanovic]

Is there any way to achieve what I want?

Currently not, import * is always disallowed. You can open a new rule change request.

[mdjermanovic]

This works as intended because pattern react matches at any level (patterns are based on the .gitignore specification), so it does match '@my-org/utils/react'. If you want a pattern that matches only top-level 'react', that would be /react. Here's a playground example with "group": ["/react"]:

https://eslint.org/play/#eyJ0ZXh0IjoiLyplc2xpbnQgbm8tcmVzdHJpY3RlZC1pbXBvcnRzOiBbXCJlcnJvclwiLCB7XG4gICAgICAgIFwicGF0dGVybnNcIjogW1xuICAgICAgICAgIHtcbiAgICAgICAgICAgIFwiZ3JvdXBcIjogW1xuICAgICAgICAgICAgICBcIi9yZWFjdFwiXG4gICAgICAgICAgICBdLFxuICAgICAgICAgICAgXCJpbXBvcnROYW1lc1wiOiBbXG4gICAgICAgICAgICAgIFwiZm9yd2FyZFJlZlwiXG4gICAgICAgICAgICBdLFxuICAgICAgICAgICAgXCJtZXNzYWdlXCI6IFwiVXNlIG91ciB0eXBlLXNhZmUgd3JhcHBlciBmcm9tIFxcXCJmb29cXFwiIGluc3RlYWQuXCJcbiAgICAgICAgICB9XG4gICAgICAgIF1cbiAgICAgIH1dKi9cblxuaW1wb3J0IHsgZm9yd2FyZFJlZiBhcyBvcmlnaW5hbEZvcndhcmRSZWYgfSBmcm9tICdyZWFjdCdcbmltcG9ydCB7IGZvcndhcmRSZWYgYXMgbW9kaWZpZWRGb3J3YXJkUmVmIH0gZnJvbSAnQG15LW9yZy91dGlscy9yZWFjdCdcbiIsIm9wdGlvbnMiOnsiZW52Ijp7fSwicnVsZXMiOnt9LCJwYXJzZXJPcHRpb25zIjp7ImVjbWFGZWF0dXJlcyI6e30sImVjbWFWZXJzaW9uIjoibGF0ZXN0Iiwic291cmNlVHlwZSI6Im1vZHVsZSJ9fX0=

Note that this also disallows import * as React from 'react'.

[bengry]

Note that this also disallows import * as React from 'react'.

Thanks. This is something I wanted to avoid:

Note that using this:

{
  "name": "react",
  "importNames": ["forwardRef"],
  "message": "..."
}

Is not good enough since it now errors on all of these lines:

import * as React from 'react';

Which, while technically correct (since you can then use React.forwardRef) is too much of an overhead, and not what I want to fix here. I'll prevent usage of React.forwardRef using another rule (no-restricted-syntax maybe).

Is there any way to achieve what I want? Seems like a missing use-case for this rule. Perhaps an exact: true option could be added to the object?