feat(eslint): introduce `@nrwl/nx/enforce-module-boundaries` to prevent using transitive dependencies

Describe the issue:

'import/no-extraneous-dependencies' rule is unable to handle following situation (single version policy for devDeps and monorepo packages):

// @filename package.json
{
  "dependencies": {
  },
  "devDependencies": {
     "lib-a": "1.0.0",
     "lib-b": "1.0.0",
  }
}

// @filename packages/react-foo/package.json
{
  "dependencies": {
        "@fluentui/react-one": "1.0.0"
  },
  "devDependencies": {
       "@fluentui/scripts": "1.0.0"
  }
}

// @filename packages/react-foo/src/hello.stories.ts

// 🚨 error, because `react-two` is not defined as dependency - ✋THIS IS INCORRECT ✋
// WHY: 
// - @fluentui/react-two is a monorepo package
// - @fluentui/react-two is used only for non production code (stories/tests/config)
import {Two} from '@fluentui/react-two";

// @filename packages/react-foo/src/implementation.ts

// ✅ no errors, because `react-one` is defined as dependency of this package
import {One} from '@fluentui/react-one"

Solution

After [link], import/no-extraneous-dependencies was turned off for non production files for reasons specified in this issue.

With that we know wont' trigger error if someone imports a transitive dev dependencies in non production code ( this is not the end of the world for sure). We would still like to prevent such a behaviour. thankfully NX eslint plugin comes with such a rule:

{
 "@nrwl/nx/enforce-module-boundaries": ["error", {"banTransitiveDependencies": true}]
}

Note that this rule will check only dependencies within root package.json - single version policy. so to be completely covered - we need to migrate whole monorepo to this approach

Related issues

• https://github.com/microsoft/fluentui/issues/21395

Start with the root package.json, packages/react-foo/package.json, and the ESLint configuration that governs packages/react-foo. Compare the stories/tests/config example with the production implementation example, and read related issue 21395 for the monorepo dependency approach. Done means the enforce-module-boundaries rule prevents transitive dependency imports without incorrectly rejecting declared package dependencies.