build: migrate monorepo to Yarn v4 workspaces#1054
build: migrate monorepo to Yarn v4 workspaces#1054gspencergoog wants to merge 2 commits intogoogle:mainfrom
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
ditman
left a comment
ditman
left a comment
There was a problem hiding this comment.
Removing the .npmrcs will be a problem to release the packages using the Exit Gate, it seems? How does publishing through yarn work?
| @a2ui:registry=https://us-npm.pkg.dev/oss-exit-gate-prod/a2ui--npm/ | ||
| //us-npm.pkg.dev/oss-exit-gate-prod/a2ui--npm/:always-auth=true |
There was a problem hiding this comment.
This is needed to be able to publish the package through go/oss-exit-gate-release-npm. What is the equivalent in yarn?
There was a problem hiding this comment.
Okay, I think I updated the .yarnrc.yml to configure the registry this way. I don't think we'll know if it works until we try to publish.
There was a problem hiding this comment.
Turns out we can only update the registry when we actually publish. If I put it into the .yarnrc.yml, then CI will fail because it doesn't have a token.
renderers/angular/package-lock.json
Outdated
There was a problem hiding this comment.
Lock files seem to be also required by go/oss-exit-gate-release-npm, are we ignoring the yarn locks?
There was a problem hiding this comment.
There's a global yarn.lock, github didn't render the huge diff!
There was a problem hiding this comment.
Yes, I was hoping we didn't need them. I'll rethink that and see.
There was a problem hiding this comment.
I didn't see any mention of lock files in the docs. I don't think we need to include them. But no, we aren't ignoring yarn locks, but it's set up as a monorepo, so there's only one.
|
|
||
| nodeLinker: node-modules | ||
|
|
||
| yarnPath: .yarn/releases/yarn-4.13.0.cjs |
There was a problem hiding this comment.
This is odd, are we shrink-wrapping the whole yarn executable? Should this be a devDependency somewhere?
There was a problem hiding this comment.
Turns out this is redundant with packageManager, so I removed it and the .yarn/releases directory.
There was a problem hiding this comment.
Oh. Actually not. It means that you have to enable corepack on your machine (every dev would have to). I went back to keeping the yarn executable.
The reason you don't put it in dev dependencies is the chicken-and-egg problem: You need a package manager to install your devDependencies. If Yarn is a devDependency, you would need Yarn to install Yarn.
|
I think I've resolved all the issues. I updated the publishing doc for yarn-based instructions but crucially, I haven't tried them. They look reasonable, but we would need to vet them at the next publish time to make sure they work. |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Ported minimal build and stability fixes from yarn_fixes branch to yarn branch: - Fixed TSConfig path mappings in markdown-it and Angular samples. - Updated Angular build output paths in angular.json and ng-package.json. - Updated READMEs and Dockerfiles to use yarn instead of npm/pnpm. - Added SSR stability fixes in Composer (next/dynamic) and Angular samples (isPlatformBrowser). - Fixed mock data types in React shell sample. - Fixed imports in Personalized Learning sample to match package name. Verified with successful `yarn build:all`.
2 participants
Description
This pull request modernizes the repository's build infrastructure by adopting Yarn v4 workspaces. The primary goal is to simplify dependency management and streamline build processes across the monorepo. By centralizing configuration and adopting workspace-aware commands, the change improves maintainability and consistency in CI/CD pipelines and local development environments.
Highlights