feat: introduce dual-generation monorepo architecture #5785
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Contributor
📚 Branch Preview🔍 Visual Regression Test ResultsWhen a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:
Deployed to Azure Blob Storage: If the changes are expected, update the |
Contributor
Tachometer resultsCurrently, no packages are changed by this PR... |
27 tasks
caseyisonit
added
do-not-merge
rubencarvalho
force-pushed
the
barebones
branch
from
ec211ef to
22de59a
Compare
rubencarvalho
changed the title
rubencarvalho
added
Status: Ready for review
- Add root package.json with workspace delegating scripts - Configure Yarn 4 with monorepo workspaces - Set up lint-staged, commitlint, and patch-package - Update .gitignore for dual-workspace structure - Configure root-level linting and formatting rules
- Create 2nd-gen workspace with separate package.json - Add @spectrum-web-components/core package with shared base classes - Implement 2nd-gen components: asset, alert-banner, divider, progress-circle, status-light, report-abuse-button - Add @adobe/swc aggregator package - Configure Vite-based Storybook for Spectrum 2 - Set up Vitest and Playwright testing infrastructure - Add TypeScript path mappings for cross-generation imports
- Update CircleCI config for 1st-gen and 2nd-gen paths - Modify GitHub workflows for monorepo structure - Update changeset configuration for dual-workspace - Add Cursor rules for contributor documentation
- Add comprehensive contributor documentation - Document 1st-gen vs 2nd-gen split and migration paths - Include component migration step-by-step guides - Add project planning and workstream documentation - Document release processes and testing strategies
…5851) * chore: update and streamline publishing workflow for new monorepo structure Refactors the publishing and release management workflow to support the dual-generation monorepo architecture: - Update Changesets configuration to recognize both 1st-gen and 2nd-gen workspaces, enabling independent versioning strategies - Refactor release scripts to delegate to generation-specific publishing workflows rather than operating on a flat package structure - Update CI/CD publishing jobs to build, test, and publish both generations with appropriate dependency handling for the shared Core library - Preserve existing 1st-gen package publishing behavior to avoid disruption to current consumers This workflow enables continuous delivery of improvements to 1st-gen customers while supporting independent 2nd-gen package releases.
rubencarvalho
force-pushed
the
barebones
branch
from
3ff495e to
fd099fd
Compare
nikkimk
requested changes
Nov 3, 2025
Contributor
nikkimk
left a comment
nikkimk
left a comment
There was a problem hiding this comment.
The docs are looking very very nice. Here's what I have for feedback today.
CONTRIBUTOR-DOCS/01_contributor-guides/03_working-in-the-swc-repo.md
Outdated
Show resolved
Hide resolved
CONTRIBUTOR-DOCS/01_contributor-guides/04_making-a-pull-request.md
Outdated
Show resolved
Hide resolved
CONTRIBUTOR-DOCS/01_contributor-guides/04_making-a-pull-request.md
Outdated
Show resolved
Hide resolved
TarunAdobe
reviewed
Nov 4, 2025
rubencarvalho
force-pushed
the
barebones
branch
from
b117fc5 to
a9e20e1
Compare
rubencarvalho
force-pushed
the
barebones
branch
from
1d127dd to
d0d9c8e
Compare
caseyisonit
approved these changes
Nov 4, 2025
Contributor
caseyisonit
left a comment
caseyisonit
left a comment
There was a problem hiding this comment.
INSANE IN THE MEMBRANE
nikkimk
approved these changes
Nov 4, 2025
| - Override properties that need type narrowing with S2-specific types | ||
| - In API ADDITIONS section (if applicable): | ||
| - Add any S2-only properties (e.g., `subtle`, `outline` for Badge) | ||
| - Re-export any S2-specific types and constants as needed for backward compatibility, marking them as deprecated |
Contributor
There was a problem hiding this comment.
Why would we be deprecating S2-specific types? Did we mean S1-specific?
Contributor
Author
There was a problem hiding this comment.
Great catch - I updated it too!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR restructures the Spectrum Web Components repository into a dual-generation monorepo to support side-by-side development of 1st-gen and 2nd-gen components. This architectural change is foundational to the project's strategic objectives and enables the team to pursue multiple goals in parallel without disruption.
Key changes:
1st-gen/workspace, preserving all existing functionality2nd-gen/workspace with initial package structure for@spectrum-web-components/coreand@adobe/swc@spectrum-web-components/core) containing abstract, non-rendering base classes that both generations can extendMotivation and context
This change implements the "side-by-side development" strategy outlined in our project objectives, providing two critical advantages:
Isolation: 1st-gen and 2nd-gen workspaces are separated, allowing 2nd-gen to be built iteratively from the ground up without risking breakage to 1st-gen. Disruptive changes (tooling overhauls, Spectrum CSS unification, full-fidelity Spectrum 2 implementation) are confined to
2nd-gen/, while 1st-gen continues operating "as-is".Colocation: Both generations live in the same repository and share core component logic through abstract base classes in
@spectrum-web-components/core. This means:This architectural foundation enables the team to work efficiently on multiple strategic objectives in parallel:
See
CONTRIBUTOR-DOCS/03_project-planning/01_objectives-and-strategy.mdfor detailed strategic context.Related issue(s)
Screenshots (if appropriate)
Author's checklist
Reviewer's checklist
patch,minor, ormajorfeaturesManual review test cases
All testing and validation happening under SWC-1236.