Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Pnpm separate from Npm #9274

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Make Pnpm separate from Npm #9274

wants to merge 4 commits into from

Conversation

fviernau
Copy link
Member

@fviernau fviernau commented Oct 11, 2024

Rewrite large parts of Pnpm from scratch to figure out all information based on pnpm CLI output, and
remove the inheritance from Npm.

Part of #9261.

Copy link

codecov bot commented Oct 11, 2024

Codecov Report

Attention: Patch coverage is 84.16667% with 19 lines in your changes missing coverage. Please review.

Project coverage is 67.67%. Comparing base (507ee30) to head (c5f1c7e).

Files with missing lines Patch % Lines
...e-managers/node/src/main/kotlin/pnpm/ModuleInfo.kt 57.14% 9 Missing ⚠️
...package-managers/node/src/main/kotlin/pnpm/Pnpm.kt 91.42% 1 Missing and 5 partials ⚠️
...node/src/main/kotlin/pnpm/PnpmDependencyHandler.kt 86.20% 0 Missing and 4 partials ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##               main    #9274      +/-   ##
============================================
+ Coverage     67.47%   67.67%   +0.20%     
- Complexity     1200     1232      +32     
============================================
  Files           241      244       +3     
  Lines          8506     8626     +120     
  Branches        904      911       +7     
============================================
+ Hits           5739     5838      +99     
- Misses         2403     2413      +10     
- Partials        364      375      +11     
Flag Coverage Δ
funTest-docker 62.08% <84.16%> (+1.48%) ⬆️
funTest-non-docker 33.57% <ø> (ø)
test 37.00% <1.66%> (-0.50%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@fviernau fviernau changed the title Pnpm rewrite Make Pnpm separate from Npm Oct 11, 2024
@fviernau fviernau force-pushed the pnpm-rewrite branch 6 times, most recently from 5e3706e to f29ee32 Compare October 11, 2024 11:05
@fviernau fviernau force-pushed the pnpm-rewrite branch 2 times, most recently from 3f9123c to f590776 Compare October 24, 2024 13:38
@fviernau fviernau force-pushed the pnpm-rewrite branch 3 times, most recently from 4d83590 to 21eacdd Compare October 24, 2024 20:38
@fviernau fviernau marked this pull request as ready for review October 24, 2024 20:39
@fviernau fviernau requested a review from a team as a code owner October 24, 2024 20:39
@fviernau fviernau force-pushed the pnpm-rewrite branch 2 times, most recently from 9d3df9a to 5a995cd Compare October 25, 2024 07:20
@fviernau fviernau force-pushed the pnpm-rewrite branch 3 times, most recently from 957fa2f to 3c0b68d Compare October 25, 2024 10:03
@fviernau fviernau force-pushed the pnpm-rewrite branch 3 times, most recently from fd69f17 to aa9247d Compare October 25, 2024 10:17
@sschuberth

This comment was marked as resolved.

@fviernau fviernau force-pushed the pnpm-rewrite branch 2 times, most recently from 07e2f98 to 259c255 Compare October 25, 2024 12:07
@fviernau

This comment was marked as resolved.

@fviernau fviernau enabled auto-merge (rebase) October 25, 2024 12:30
@@ -0,0 +1,177 @@
/*
* Copyright (C) 2019 The ORT Project Authors (see <https://github.com/oss-review-toolkit/ort/blob/main/NOTICE>)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On a related note, I only skimmed other the code changes in this file due to a lack of time. As also the expected output changes, it's a bit hard to understand just from the diff whether the implementation is correct. However, I trust that you did the mentioned comparison to NPM results to get confidence that the new expected results are more correct than the old ones.

Copy link
Member Author

@fviernau fviernau Oct 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pnpm list outputs a tree. Maybe this helpds with checking. Comparing with npm you can easily reproduce e.g. with a difftool comparing the two expected results for babel.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Above mentioned comparison should give a good idea that the change is highly likely correct (without verifying the change manually against the list output)

plugins/package-managers/node/src/main/kotlin/pnpm/Pnpm.kt Outdated Show resolved Hide resolved
plugins/package-managers/node/src/main/kotlin/pnpm/Pnpm.kt Outdated Show resolved Hide resolved
Scope.DEV_DEPENDENCIES -> "--dev"
}

val json = run(workingDir, "list", "--json", "--recursive", "--depth", "10000", scopeOption).stdout
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can we confidently limit the depth to 10000 now if previously it was -1?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

10000 prints out more than -1

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really? Isn't -1 an alias for "unlimited"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seem like.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now I'm confused. If -1 is an alias for "unlimited", shouldn't -1 print out more than 10000 then, and not the other way around? And shouldn't we stick with -1 then?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you try out -1? (I wonder why you are so sure that this works)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pnpm list --help | grep depth
      --depth -1           Display only projects. Useful in a monorepo. `pnpm ls
                           -r --depth -1` lists all projects in a monorepo
      --depth <number>     Max display depth of the dependency tree
      --depth 0            Display only direct dependencies

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder why you are so sure that this works

Because it's being used in the existing code. But now I realize the use is in a different context that does not apply here.

Anyway, the question remains why it is valid to artificially limit the depth of the dependency tree now at an (arbitrary?) number of 10000. I would have expected no limit at all, or if there was a limit, it should be configurable via a package manager specific option to go into the direction of #5626.

Copy link
Member Author

@fviernau fviernau Oct 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To my understanding there is simply no way to make the command work without a limit.
So, using a large value in my opinion makes sense. I don't think 10k is too small. In fact it is so large that it is only a theroretical problem IMO. ORT's dependency graph breaks the cycles anyway and I doubt the depth limit could be exceeded without printing cycles.

If you don't like it still, please make a counter proposal.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it's being used in the existing code. But now I realize the use is in a different context that does not apply here.

I don't know what context you are talking about. But previously existing code didn't call this command at all.

Make things consistent again in this regard. This is a fix-up for
4e19bbd.

Signed-off-by: Frank Viernau <[email protected]>
Prepare for re-use in an upcoming change.

Signed-off-by: Frank Viernau <[email protected]>
Prepare for adding further `Pnpm` specific classes.

Signed-off-by: Frank Viernau <[email protected]>
Stop inheriting from `Npm` and rely entirely on the output of `pnpm`
commands to figure out the necessary information. For example, do not
re-construct the dependency from the file structure within
`node_modules`, but rely on `pnpm list` instead. This reduces
complexity and makes the implementation easy to understand, maintain
and change.

From the diff of the expected result files it becomes aparent that this
change contains the following fixes:

1. project-with-lockfile: `htmlparser2` now dependends on
   `domutils 1.7.0` instead of `domutils 1.5.1`, which is in line with
   the dependency tree output by `pnpm list`
2. workspaces: The cyclic reference from the workspace root project to
   itself is now included.
3. babel: A lot of changes in the dependency tree which thereby aligns
   with the output of `pnpm list`. Comparing the new behavior with the
   one from `NPM` for the Babel project shows that the differences
   become very small. These differences can be explained either by
   the two package managers indeed behaving differently or by a bug in
   ORT's `NPM` implementation. The latter seems likely and should be
   investigated. For example, by re-writing `Npm` to obtain all
   information solely from `npm` CLI output.

Also note that it is good to drop the `--shamefully-hoist` command line
option, because it is not needed and its use is discouraged. Omitting
it may also reduce the amount of warnings.

Signed-off-by: Frank Viernau <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants