fix(release): republish types as 1.0.1 — 1.0.0 is permanently unavailable on npm - #113
Merged
Conversation
Two unrelated things that both have to land before the registry is healthy.
**types 1.0.1.** `@contentrain/types@1.0.0` was published on 2025-01-04 and
later unpublished. npm reserves an unpublished version number permanently, so
when the release sequence reached 1.0.0 again the registry refused it with a
400. Five of six packages published; types did not.
`workspace:*` resolves to an exact version at publish time, so mcp@3.0.0,
query@7.0.2 and contentrain@0.9.0 all shipped pinned to a version that does
not exist and cannot be created. All three fail to install with ETARGET —
verified against the live registry.
The changeset bumps types to patch; `updateInternalDependencies: "patch"`
carries the three dependents. Nothing about the code changes, and 1.0.0 never
reached anyone.
Worth doing later: `workspace:^` instead of `workspace:*` would have published
`^1.0.0` and healed itself the moment 1.0.1 landed, without republishing the
dependents at all.
**A timeout I dropped.** Converting tools/content.test.ts to the template+clone
pattern replaced its header, and took `vi.setConfig({ testTimeout: 120000 })`
with it. The file fell back to the 30s package default and a test that runs in
2.1s alone took over 30s with all six packages competing for the machine —
reported as a test failure rather than as contention. It survived both PR CI
runs, which is what a load-dependent flake does.
Declaration restored, and the package floor raised 30s -> 60s, because relying
on each file to remember is precisely what just failed. Files doing heavy git
work still declare their own 120s. A genuine hang now costs 60s once instead
of 30s, which is a cheaper mistake than a false red.
✅ Deploy Preview for contentrain-ai ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
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.
Three packages are broken on npm right now
@contentrain/mcp@3.0.0,@contentrain/query@7.0.2andcontentrain@0.9.0cannot be installed:
Verified against the live registry, not inferred.
Why
@contentrain/types@1.0.0was published on 2025-01-04 and laterunpublished —
npm view @contentrain/types versionslists only 0.7.0, 0.8.0,0.9.0, but
npm view … timestill carries a1.0.0entry. npm reserves anunpublished version number permanently, so when the release sequence climbed
back to 1.0.0 the registry refused it:
Five of the six packages published; types did not.
workspace:*resolves to anexact version at publish time, so the three packages that depend on types went
out pinned to
1.0.0— a version that does not exist and cannot be created.@contentrain/rules@0.7.0and@contentrain/skills@0.8.0are unaffected; theydo not depend on types.
The fix
One changeset bumping types to patch.
updateInternalDependencies: "patch"carries the dependents:
@contentrain/types@contentrain/mcp@contentrain/querycontentrainNo code changes. 1.0.0 never reached anyone, so skipping it costs nothing.
The broken versions are left published rather than unpublished — unpublishing
is what created this situation, and doing it again would burn three more
version numbers permanently. The new releases become
latest.Also: a timeout I dropped
Unrelated, but it has to land before main is green.
Converting
tools/content.test.tsto the template+clone pattern replaced itsheader and took
vi.setConfig({ testTimeout: 120000 })with it. The file fellback to the 30s package default, and a test that runs in 2.1s alone took over
30s with all six packages competing for the machine — reported as a test
failure rather than as contention. It passed both PR CI runs, which is what a
load-dependent flake does.
Declaration restored, and the package floor raised 30s → 60s: relying on each
file to remember is exactly what just failed. Files doing heavy git work still
declare their own 120s. A genuine hang now costs 60s once rather than 30s,
which is the cheaper mistake.
Follow-up worth considering
workspace:^instead ofworkspace:*would have published^1.0.0ratherthan
1.0.0, and this would have healed itself the moment 1.0.1 landed —without republishing the dependents at all. Not changed here; it affects every
package and belongs in its own PR.
pnpm lint,typecheck,build, 1650 tests,plugin:build,release:check— all green.
🤖 Generated with Claude Code