Skip to content

build: migrate monorepo to Yarn v4 workspaces#1054

Open
gspencergoog wants to merge 20 commits intogoogle:mainfrom
gspencergoog:yarn
Open

build: migrate monorepo to Yarn v4 workspaces#1054
gspencergoog wants to merge 20 commits intogoogle:mainfrom
gspencergoog:yarn

Conversation

@gspencergoog
Copy link
Copy Markdown
Collaborator

@gspencergoog gspencergoog commented Apr 2, 2026

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

  • Monorepo Migration: Migrated the project from independent npm workspaces to a centralized Yarn v4+ workspace configuration, enabling topological builds and unified dependency management.
  • Build System Refactoring: Updated CI workflows and local scripts to use Yarn commands (yarn build, yarn test) and added root-level workspace scripts for bulk operations.
  • Dependency Management: Replaced file-based local dependencies with workspace:* protocol and unified the lockfile at the repository root.
  • Bug Fixes and UI Improvements: Fixed an AST destructuring crash in a2a-chat-canvas via corrected tsconfig paths and replaced static SSR imports with dynamic imports in widget-builder to resolve hydration issues.

gemini-code-assist[bot]

This comment was marked as resolved.

@google google deleted a comment from gemini-code-assist bot Apr 2, 2026
workspace configuration.

Key changes:
- Adds root package.json and .yarnrc.yml for topological builds using
  `yarn workspaces foreach`.
- Unifies `yarn.lock` at the repository root and removes localized
  package-lock.json and .npmrc files.
- Refactors `npm run` steps in CI workflows to use `yarn build` and
  `yarn test`.
- Fixes `a2a-chat-canvas` internal AST destructuring crash caused by
  incorrect tsconfig path mapping. Sets `paths` to the built `dist` folder.
- Replaces static SSR imports in `widget-builder` shell with dynamic imports
  to prevent CustomElementRegistry hydration collisions.
- Moves `@a2ui/angular` and `@a2ui/web_core` to peerDependencies in
  Angular sample projects.
@gspencergoog gspencergoog marked this pull request as ready for review April 2, 2026 19:33
@gspencergoog gspencergoog requested a review from ditman April 2, 2026 19:44
Copy link
Copy Markdown
Collaborator

@ditman ditman left a comment

Choose a reason for hiding this comment

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

Removing the .npmrcs will be a problem to release the packages using the Exit Gate, it seems? How does publishing through yarn work?

Comment on lines -1 to -2
@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
Copy link
Copy Markdown
Collaborator

@ditman ditman Apr 2, 2026

Choose a reason for hiding this comment

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

This is needed to be able to publish the package through go/oss-exit-gate-release-npm. What is the equivalent in yarn?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Maybe related? yarnpkg/berry#6191

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Collaborator

@ditman ditman Apr 2, 2026

Choose a reason for hiding this comment

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

Lock files seem to be also required by go/oss-exit-gate-release-npm, are we ignoring the yarn locks?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

There's a global yarn.lock, github didn't render the huge diff!

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Yes, I was hoping we didn't need them. I'll rethink that and see.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

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
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

This is odd, are we shrink-wrapping the whole yarn executable? Should this be a devDependency somewhere?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Turns out this is redundant with packageManager, so I removed it and the .yarn/releases directory.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

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.

- Update Angular projects to use 'yarn workspace' instead of relative paths.
- Scope Lit samples build CI workflow.
- Remove unsupported '--ignore-missing' flag from root scripts.
- Standardize all packages to TypeScript 5.9.3.
@gspencergoog
Copy link
Copy Markdown
Collaborator Author

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.

- Hoist wireit to workspace root
- Convert package-level build scripts to wireit (renderers, tools, specification, samples)
- Fix wireit output path restrictions for Angular sub-projects by removing output tracking
- Fix relative paths for wireit dependencies in sample packages
- Update root scripts to run topologically without unsupported flags
- Fix SSR crash in tools/composer by dynamically importing A2UIViewer with ssr: false.
- Fix TypeError: Invalid URL errors in Angular samples by adding isPlatformBrowser checks before relative fetch calls.
- Standardize peerDependencies in renderers/angular and renderers/lit to use workspace patterns (removing file: prefixes).
Add wireit explicitly to devDependencies in packages that use it for build scripts to ensure stability in strict environments.
gemini-code-assist[bot]

This comment was marked as resolved.

@google google deleted a comment from gemini-code-assist bot Apr 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

2 participants