Skip to content

Depend on @cratis/fundamentals as a peer - #2445

Closed
woksin wants to merge 1 commit into
mainfrom
feature/fundamentals-as-peer-dependency
Closed

Depend on @cratis/fundamentals as a peer#2445
woksin wants to merge 1 commit into
mainfrom
feature/fundamentals-as-peer-dependency

Conversation

@woksin

@woksin woksin commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Changed

  • @cratis/arc declares @cratis/fundamentals as a peer dependency instead of a versioned dependency. Consumers whose package manager does not install peers automatically must now declare it themselves.

Declared as a range in dependencies, which tells a package manager a copy
each is acceptable. It is not: the two copies get separate converter
registries and separate class objects, so a converter registered on one
reaches only that one, an instanceof against the other is false, and a
version pinned at the top level never reaches the nested copy - an adopted
fix can land nowhere while every build stays green.

A peer dependency is the mechanism for "exactly one of these in the tree",
which is what this actually is. The range is deliberately wide so a patch
or minor release does not force lockstep releases across repositories, and
an exact devDependency keeps this repository's own build and specs pinned.
Copilot AI lite review requested due to automatic review settings August 4, 2026 10:15
@woksin woksin added the major label Aug 4, 2026
@woksin

woksin commented Aug 4, 2026

Copy link
Copy Markdown
Contributor Author

Split out of #2442, where it was wrongly bundled with an additive generator feature.

Why major. @cratis/arc no longer brings @cratis/fundamentals transitively. npm 7+ installs peers automatically and is unaffected; Yarn Berry and pnpm without auto-install-peers are not, and a consumer there must declare it.

Why do it. Two copies in one realm is a broken outcome, not a wasteful one — each gets its own converter registry and class objects, so a converter registered on one reaches only that one, instanceof against the other is false, and a version pinned at the top level never reaches the nested copy. Measured against real published versions: a sibling declaring it as a dependency pinned to 7.16.7, in an app pinning 7.16.8, installs two copies; declared as a peer, one.

The ^7 range is deliberately wide so a patch or minor release does not force lockstep releases, and an exact devDependencies entry keeps this repository's own build pinned.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Pull request overview

Updates the @cratis/arc JavaScript package to treat @cratis/fundamentals as a peer dependency, reducing the risk of multiple physical copies being installed in consumer setups and making the dependency relationship explicit for package managers that don’t auto-install peers.

Changes:

  • Removed @cratis/fundamentals from dependencies.
  • Added @cratis/fundamentals to peerDependencies (major range).
  • Added @cratis/fundamentals as a pinned devDependency for local development/build/test.

Comment on lines +74 to 79
"peerDependencies": {
"@cratis/fundamentals": "^7"
},
"devDependencies": {
"@cratis/fundamentals": "7.16.0"
}
@woksin

woksin commented Aug 4, 2026

Copy link
Copy Markdown
Contributor Author

Closing as redundant — recombined into #2442.

Splitting this out gave each change an accurate label, but publish.yml cuts a release per merged PR touching Source/**, so it would also have produced two Arc releases. One release is preferred, and #2442 now carries both changes labelled major, which is the correct bump for a release containing this one.

@woksin woksin closed this Aug 4, 2026
@woksin
woksin deleted the feature/fundamentals-as-peer-dependency branch August 4, 2026 10:23
@woksin

woksin commented Aug 4, 2026

Copy link
Copy Markdown
Contributor Author

Superseded by #2446, which carries this unchanged so the whole set lands as one release rather than four. Closing so it cannot be merged twice — the branch is untouched.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants