Add the "lean bundle" use-case no-restricted-imports

From discussions with @ljharb in https://github.com/benmosher/eslint-plugin-import/issues/642 I realised that what I wanted to add in eslint-plugin-import is actually already supported by no-restricted-imports and no-restricted-modules. It just wasn’t a very obvious use case in the documentation.

Let me explain a bit what the use case is! Basically we have a plugin https://github.com/eslint-plugins/eslint-plugin-lean-imports that warns people when they pull in a full module instead of pulling just a single file. Some packages advise people to pull single files in order to have smaller bundles (eg: lodash, react-bootstrap).

// with "lean-imports/import": [1, [ "react-bootstrap "] ]
import RB from 'react-bootstrap'; // warns
const RB = require('react-bootstrap'); // warns

const Button = require('react-bootstrap/lib/button'); // passes

As I said, I can have a similar behavior by setting

{
  "no-restricted-imports": [2, "react-bootstrap"],
  "no-restricted-modules":[2, "react-bootstrap"],
}

The issue is just that the error message is not really tailored at that behavior and is really obscure if that is what the wanted behavior was: 'react-bootstrap' import is restricted from being used. It would be nice if there was a way to specify something more tailored for these packages (like have different “sections” or something along that), or have a message that supports both!

The message we have in lean-import is the following Importing the entire lodash library is not permitted, please import the specific functions you need which tells the user why it errored.

Also, Adding documentation about that specific use case in the doc of both of these rules could help people learn about it!

I’m willing to do the PRs with these, I’m just not sure of the approach here.

[dozoisch]

@ilyavolodin Alright! Yes, it’ll support both (old and new)! I should have some time to do it today or tomorrow.

[ljharb]

I’d suggest making the schema allow an array of either a string (current), or { "name": "<current string>", "message": "<optional message>" } - that lets it be a smooth backwards-compatible upgrade on top of the current schema, and mirrors no-restricted-properties for “message”.