-
-
Notifications
You must be signed in to change notification settings - Fork 8.9k
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
Download Yarn Berry with Corepack rather than Yarn 1.x #9772
Conversation
@@ -65,9 +65,7 @@ junit.xml | |||
|
|||
# Yarn | |||
# https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored | |||
.pnp.* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See the comments to .yarnrc.yml
below for explanation.
.yarn/* | ||
.yarnrc.yml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previously automatically generated on the fly by our custom Ant-based logic. This Ant-based logic is now deleted, and instead this file is checked into Git. This removes a layer of indirection and makes the code simpler, since the file that is used is now static rather than dynamically generated.
@@ -78,7 +76,4 @@ node/ | |||
node_modules/ | |||
|
|||
# Generated JavaScript Bundles | |||
jsbundles |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using a more specific path to jsbundles
, since there is only a single such directory.
# In case someone accidentally runs npm install instead of yarn install | ||
package-lock.json |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using NPM is not supported, and having code in the source tree to handle an unsupported configuration by silently ignoring it (rather than failing fast) violates the principle of least surprise.
@@ -7,8 +7,6 @@ node/ | |||
|
|||
.git | |||
|
|||
.yarnrc.yml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No longer automatically generated, so we can adhere to Prettier formatting rules now.
enableGlobalCache: false | ||
nodeLinker: node-modules |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As recommended in https://github.com/eirslett/frontend-maven-plugin/blob/4a501a10677716a0e6676b603e3b93bc6bf319f1/frontend-maven-plugin/src/it/corepack-provided-integration/.yarnrc.yml. Note that without the nodeLinker
line eirslett/frontend-maven-plugin#1157 does not actually work, instead complaining about corepack
not being listed in package.json
. I filed for another day any latent curiosity about why this might be the case (probably a deficiency in frontend-maven-plugin
documentation at the very least).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not using 'pnp' https://yarnpkg.com/migration/pnp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see no reason why using PNP would solve the problem statement described in this PR description.
To run the Yarn frontend build, after [building the WAR file](#building-the-war-file), add the downloaded versions of Node and Yarn to your path: | ||
|
||
```sh | ||
export PATH=$PWD/node:$PWD/node/yarn/dist/bin:$PATH | ||
export PATH=$PWD/node:$PWD/node/node_modules/corepack/shims:$PATH |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adapting to the changes in pom.xml
below.
@@ -1,20 +0,0 @@ | |||
work |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unneeded now that the corresponding entries are in the root directory's .gitignore
file.
<!-- frontend-maven-plugin will install this Yarn version as bootstrap, then hand over control to Yarn Berry. --> | ||
<yarn.version>1.22.19</yarn.version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yarn 1.x is now no longer needed to bootstrap Yarn Berry, since we now use Corepack for this purpose.
<!-- maven-antrun-plugin will download this Yarn version. --> | ||
<yarn-berry.version>4.5.0</yarn-berry.version> | ||
<yarn-berry.sha256sum>cc00dce5de4f68d11450519a0f69eadf2a1cbe5cc0d8e740bfac817a31d76874</yarn-berry.sha256sum> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This duplicate information is no longer needed, as this information is consumed from package.json
via Corepack.
That seems like evidence that you have failed to build Jenkins core, but it does not seem like evidence that there is a general issue with this PR, as the Testing Done section is thorough, including both local testing and CI testing. I am inclined to believe there is something wrong on your side, but that this should not block us from proceeding with this PR. |
corepack
My build failed with:
Steps I followed were: gh pr checkout 9772
mvn clean install -P quick-build Env:
Apple M2, on Sequoia |
I managed to fix it by running and then the next downloaded version was setup correctly. I wasn't able to reproduce it by trying to revert to my previous state: rm -rf node/
git checkout master
mvn clean install -P quick-build
git checkout -
mvn clean install -P quick-build |
@@ -0,0 +1,2 @@ | |||
enableGlobalCache: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the reasoning for disabling this? it seems to be enabled by default.
(not a blocker)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was copied from the example here: https://github.com/eirslett/frontend-maven-plugin/blob/4a501a10677716a0e6676b603e3b93bc6bf319f1/frontend-maven-plugin/src/it/corepack-provided-integration/.yarnrc.yml
There is no comment there explaining the reason, but if I had to guess, it would be to follow the general philosophy of frontend-maven-plugin
, as explained in its README
:
Node/corepack and any package managers will only be "installed" locally to your project. It will not be installed globally on the whole system (and it will not interfere with any Node/corepack installations already present).
The design seems to be to remain completely isolated from the system installation of Node/Corepack, and I suppose the developer was trying to adhere to that philosophy here by avoiding the sharing of any caches with the system installation.
OK, your original error message is definitely related to this PR, and I am glad you were able to solve it by cleaning the working directory. I had tested with a clean working directory as well. Just to be sure, I ran a build successfully in a Docker container without any existing Maven cache, and it worked correctly there, so I think this PR has no issues on a clean environment. So I think we will just need to make sure that developers who have an existing checkout run |
corepack
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
It's not a new phenomenon that moving around JS related files breaks the local build with unclean contents. The same happened due to #9718 when switching between "before" and "after" branches, and the same happened a few years ago. Perhaps this just is the first time it happens when moving forward rather than backward. |
Indeed, this is yet another ancient build bug. I will try to fix |
/label ready-for-merge This PR is now ready for merge, after the pending security release, we will merge it if there's no negative feedback. Thanks! |
Decrease the maintenance burden in this repository by replacing our custom Ant (!) based code to bootstrap Yarn Berry using Yarn 1.x with Corepack as implemented in eirslett/frontend-maven-plugin#1157.
Testing done
Introduced stylelint and eslint failures in both CI and local builds. In both cases, verified that the error message was readable: in local builds, on the CLI; and in CI builds, in the Jenkins UI.
For the local builds, tested without path modifications on my local machine with Node LTS installed as well as with path modifications inside of a Docker container with no existing Node/NPM installation, thus exercising both supported paths as documented in
CONTRIBUTING.md
.Proposed changelog entries
N/A
Proposed upgrade guidelines
N/A
Submitter checklist
Desired reviewers
@mention
Before the changes are marked as
ready-for-merge
:Maintainer checklist