This PR adds support for package.json based secondary entry points and
implements fix for situation when package imports base entry point as
dynamic dependency and secondary entry point as static dependency.
## Current Behavior
When the package is imported from itself, check for a secondary entry
point checks only Angular-style secondary entry points.
When package is importing from the same library as dynamic import from
root and static import from secondary entry point we still get linter
errror.
## Expected Behavior
Check for secondary entry points should also support standard
package.json-based entry points.
Importing from the same library as dynamic import from root and static
import from secondary entry point should be allowed.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#18552
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
I was looking at the source to understand how `sourceRoot` is used and
saw it was referenced in the eslint-plugin but it turns out it isn't
actually used
## Current Behavior
This parameter isn't used
## Expected Behavior
The parameter should be removed
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: FrozenPandaz <jasonjean1993@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The `@nx/dependency-checks` rule sometimes doesn't apply all identified
fixes and wrongly succeeds. ESLint performs multiple passes to try to
apply fixes, and in each pass the rule receives the updated source code
with the previously applied fixes. This allows merging different fixes,
but the `@nx/dependency-checks` rule always reads the `package.json`
file from the filesystem, caches it globally, and mutates it. It never
uses the updated source code provided in the rule context.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `@nx/dependency-checks` rule should apply all identified fixes [as
long as they don't
conflict](https://eslint.org/docs/latest/extend/custom-rules#conflicting-fixes).
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27412
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#21889
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
## Current Behavior
<!-- This is the behavior we have today -->
We only ever discover one version of an external dependency for the
file-map.json. This means the `@nx/dependency-checks` lint rule can
produce incorrect failures when multiple copies of a dependency exist
within a workspace.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
In the file-map.json the project specific version of a package (if
multiple exist) is preferred and therefore the lint rule produces
accurate results.
---
For example, in a repo where the root package.json has lodash@4.0.0
(which becomes `npm:lodash` on graph) and the foo project has
lodash@3.0.0:
**Before**
**After**
## Performance
`NX_ISOLATE_PLUGINS=true NX_PERF_LOGGING=true NX_DAEMON=false nx show
project nx --json false`
** Before **
Time for 'build typescript dependencies' 505.52144700009376
** After **
Time for 'build typescript dependencies' 701.247584999539
