Migrate from yarn v1 to npm

[andreasgerstmayr]

Which problem is this PR solving?

• simplify build by using the default package manager for Node.js
• yarn v1 is not actively maintained anymore
• obsoletes Upgrade yarn to v3.8.5 #2459

Description of the changes

• move from yarn v1 to npm

How was this change tested?

• jaeger all-in-one & npm run start
• GitHub actions builds

Checklist

• I have read https://github.com/jaegertracing/jaeger/blob/master/CONTRIBUTING_GUIDELINES.md
• I have signed all commits
• I have added unit tests for the new functionality
• I have run lint and test steps successfully
  • for jaeger: make lint test
  • for jaeger-ui: yarn lint and yarn test

[pavolloffay]

@yurishkuro we are having issues building jaeger-ui internally with the new build system that does not support yarn1, therefore we would like to migrate. npm seems like the best choice, we have also seen other OSS upstream projects migrating to npm (e.g. visualstudio)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.61%. Comparing base (3c88048) to head (627a8fc).
Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2462   +/-   ##
=======================================
  Coverage   96.61%   96.61%           
=======================================
  Files         254      254           
  Lines        7679     7679           
  Branches     1931     1982   +51     
=======================================
  Hits         7419     7419           
  Misses        260      260           

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

[yurishkuro]

Do we need changes to dependabot/renovate configs?

[yurishkuro]

The new commands are pretty unusable for something that we need to run often, like executing a single test. Is it possible to have some sort of shortcut? Why can't we use something like "npm test ..."?

[andreasgerstmayr]

The command propagation changed, in yarn yarn run somescript arg1 forwards arg1 to somescript, but with npm you need to write npm run somescript -- arg1, so npm can differentiate between args for npm and args for the script.

I updated the workspaces invocation, now additional args are correctly passed to the test script in the root package.json, which then forwards it to the test script of all workspaces. The invocation now is almost identical.

[yurishkuro]

we have also seen other OSS upstream projects migrating to npm (e.g. visualstudio)

Is there a blog post about that?

[andreasgerstmayr]

we have also seen other OSS upstream projects migrating to npm (e.g. visualstudio)

Is there a blog post about that?

https://code.visualstudio.com/updates/v1_94#_use-npm-as-default-package-manager
microsoft/vscode#196795

[yurishkuro]

Q: how did we ensure that package-lock.json is equivalent to yarn.lock? Specifically, there were some upgrades to yarn.lock to address vulnerabilities in transitive dependencies.

[yurishkuro]

can we provide an example from the existing tests? It's not clear what <test name> means, e.g. in this test file:

 PASS  src/utils/readJsonFile.test.js
  fileReader.readJsonFile
    ✓ rejects when given an invalid file (2 ms)
    ✓ does not throw when given an invalid file (1 ms)
    ✓ loads JSON data, successfully (8 ms)
    ✓ loads JSON data (OTLP), successfully (2 ms)
    ✓ rejects an OTLP trace (4 ms)
    ✓ rejects malformed JSON (1 ms)
    ✓ loads JSON-per-line data (1 ms)

Is it the actual title/description? Is "pattern" a reference to some regex?

[andreasgerstmayr]

It's a regex matching the full test name, i.e. test name and all surrounding describe blocks: https://jestjs.io/docs/cli#--testnamepatternregex
I've updated the text and added a link to the docs.

[andreasgerstmayr]

Q: how did we ensure that package-lock.json is equivalent to yarn.lock? Specifically, there were some upgrades to yarn.lock to address vulnerabilities in transitive dependencies.

That's a good point! I'm not sure if there is a way to prove the equivalence of the lock files. There is a tool which converts between lockfile formats called synp, but it uses the node_modules folder, so it doesn't work with optional dependencies like @rollup/rollup-linux-s390x-gnu which are present in the lockfile but are not installed in my node_modules folder. Workspace support is also experimental in this tool.

Another idea, if we regenerate the lockfile from scratch, we get the latest (as defined by the semver) versions of all (transitive) dependencies including all available CVE fixes. What do you think?

[andreasgerstmayr]

Q: how did we ensure that package-lock.json is equivalent to yarn.lock? Specifically, there were some upgrades to yarn.lock to address vulnerabilities in transitive dependencies.

That's a good point! I'm not sure if there is a way to prove the equivalence of the lock files.

Thinking more about it, I can just print a list of all dependencies and their version, sort it and then diff it with the versions of the previous lockfile. I'll do that, but in any case, I'll try to upgrade all dependencies first (in a separate PR).

• Update @types/react to 18.3.11 #2464
• Update antd to 5.21.3 #2465

[yurishkuro]

@andreasgerstmayr how do you want to handle conflicts and recent upgrades in main? I regress merging those, should've just merged this PR first.