[Suggestion]: `import/no-restricted-paths` allow exception for dynamic imports

[michaelrivet]

trafficstars

Suggestion

For the import/no-restricted-paths it would be nice to allow a rule or zone to have exceptions for dynamic imports.

Reasoning

I am working on using import/no-restricted-paths to build clear boundaries in a react web-application. As it stands I can handle probably 95% of what I'm trying to achieve, but there are some instances where I need to cross these boundaries. I do so by using the dynamic import and webpack chunks, this ensures the code is not added to my initial bundle.

An example application structure:

• /script
  • /core - Directory for global code use by all features and pages
    • /layout - Directory holding all components necessary to render a standard application layout
    • /utilities - Directory for shared utilites that all features and pages can use
  • /features - Directory for features that pages will use
    • /feature1
    • /feature2
  • /pages - Directory for full applications. The root component of a page will be rendered as a child of the root layout component
    • /page1
    • /page2

There are some instances where a subset of logic in a feature would be good to include in the /core/layout components. For example, there's a fullblown feature that lives on page1, but on the layout I want to render a paired down version of this.

Since they share functionality (state management, render logic, etc) duplicating this feature in /core/layout doesn't make sense. Instead I use dynamic imports and React.lazy to lazy load this feature.

I can ignore these lint errors and warnings, but it would be nice if the lint rule had an option to ignore dynamic imports. I would assume it's not uncommon for this rule to be in place to prevent unwanted dependencies, and in the case of dynamic imports it's not an issue.

I plan on building an example repo to demonstrate my plans, and am willing to look into addressing this if anyone thinks it's not a terrible idea.

Alternative approach

An alternative option would be to simply find a new folder structure to expose "public" features. In the features directories there are many that should not be used publicly, and perhaps just notating as such would solve this problem.