chore: merge dev into main - #96
Merged
Merged
Conversation
A release-please monorepo tags every published package on its own — `duxt@v0.4.0` beside `duxt-typesense@v0.1.0` — and until now `latest`, release discovery and the version switcher accepted only `v?X.Y.Z`, silently skipping anything else. After the first component tag a site's `latest` would have stayed on the last plain tag without any build failing. - `parseVersionTag` reads both shapes; `compareVersionTags`, `versionRelation`, release discovery and the switcher's order all go through it, so they cannot disagree about which tags are versions. - A tag's label and URL segment show the version alone (`v0.4.0`); the ref keeps the full tag, which is what Content downloads. - `tagComponent` restricts `latest` and `releases` to one package's tags. Plain tags still count under it — the history from before a repository adopted component tags. Unset, every tag is a candidate, exactly as before. - www's own duxt source names `tagComponent: 'duxt'`, so its `latest` follows the layer's releases once they are tagged `duxt@v…`. Refs #86
The root was the layer, so thirty build-time modules sat flat beside the meta configuration and a second published package had nowhere to go. - The layer moves to packages/duxt and its build-time modules into topic folders under build/ (sources, sections, bruno, openapi, search, content, og-image, git, config, cli). The files allowlist shrinks to directories; the exports map keeps every subpath name it had. - The site moves to apps/www together with the scripts and tests that read its build. The root keeps workspace and meta configuration, docs/ and the layer's CHANGELOG.md. - Root scripts delegate package tasks to `turbo run`. The cache is local only and covers only tasks whose declared inputs determine the result; typecheck, build and the checks over a build stay uncached. - The layer's dependencies are hoisted to the workspace root, because the site builds the layer's code and resolved them there while the root was the layer (typecheck and the Workers build both depend on it). - release-please runs per package with `<name>@vX.Y.Z` tags, keeps the layer's changelog at /CHANGELOG.md so every earlier edition keeps its release pages, and bridges from v0.4.0 with last-release-sha. - The npm publish moves into release-please.yml as own jobs, decided by tag and registry, because the central bodies publish the repository root. - CLAUDE.md, AGENTS.md, README, CONTRIBUTING and the branding page describe the new layout. Refs #86
ADR 0011, in all five languages: the monorepo layout, independent versions with `<name>@vX.Y.Z` tags, why the layer's changelog stays at the repository root, publishing by tag and registry, the providers' wide peer range, and Turborepo's local-only cache. It supersedes the own-repository decision recorded in #74 and #75. Refs #86
release-please credits a package only with commits touching a file under its own directory, so a feat or fix confined to root docs/, apps/www or CHANGELOG.md is silently dropped from every release. Name the trap, the dry run that shows it, and the empty commit as the one path-free carrier. Refs #86
The change landed as 77f9d20, before the move into packages/duxt, and touched only pre-move root paths, so release-please credits it to no package. An empty commit is credited to every package path, which carries it into the layer's next release. No issue reference here on purpose: release-please would print it beside the changelog entry as if this change closed that issue.
The change landed as c0a7b24, before the move into packages/duxt, and touched only pre-move root paths, so release-please credits it to no package. An empty commit is credited to every package path, which carries it into the layer's next release. No issue reference here on purpose: release-please would print it beside the changelog entry as if this change closed that issue.
The change landed as d5ad492, before the move into packages/duxt, and touched only pre-move root paths, so release-please credits it to no package. An empty commit is credited to every package path, which carries it into the layer's next release. No issue reference here on purpose: release-please would print it beside the changelog entry as if this change closed that issue.
The change landed as 54bd866, before the move into packages/duxt, and touched only pre-move root paths, so release-please credits it to no package. An empty commit is credited to every package path, which carries it into the layer's next release. No issue reference here on purpose: release-please would print it beside the changelog entry as if this change closed that issue.
The change landed as 3487d48, before the move into packages/duxt, and touched only pre-move root paths, so release-please credits it to no package. An empty commit is credited to every package path, which carries it into the layer's next release. No issue reference here on purpose: release-please would print it beside the changelog entry as if this change closed that issue.
# Conflicts: # .release-please-manifest.json # package.json
…tern A component and a pre-release that could each take the other's @ gave the tag pattern overlapping ways to split one string, which CodeQL reports as js/polynomial-redos. The tag is now cut at its last @ first and the pre-release keeps to semver's characters, so an @ after the version makes the tag not a version.
v0.5.0 was cut from main while dev carried five empty commits restating changes that had not been credited to packages/duxt. Four of them - header, the changelog animation, toc and image - shipped in 0.5.0 after all, so a last-release-sha at v0.5.0 would list them a second time. Pointing it at the last of those four leaves exactly the unreleased feat(sources) and the two fixes on packages/duxt.
Release discovery was read by the resolver but missing from the public
DuxtSourceInput type, so a site that set releases: { select: 'minor' } in its
app.config failed its typecheck although the build honoured the key.
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
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.
Automated rollup PR for changes accumulated on
dev. Mark ready when you want it to land — and use a merge commit, not squash, so individualfeat:/fix:commits stay visible to release-please.