Repository navigation
fix(deps): move @types/ramda to devDependencies - #76
Merged
Merged
Conversation
Diagram — Move @types/ramda from dependencies to devDependencies graph LR
A["package.json<br/>dependencies"] -->|remove| B["@types/ramda ~0.32.0"]
C["package.json<br/>devDependencies"] -->|add| B
Covers files changed in this PR — not the whole system. This PR moves 👍 Looks good to me! I didn’t find anything worth raising in this diff. ℹ️ Review details — 11,628 tokens · ~$0.0369 · 5.9s
Was this review helpful? React with 👍 or 👎 on this comment. |
This was referenced Oct 16, 2026
frantuma
force-pushed
the
frantuma/types-ramda-dev-dependency
branch
from
October 20, 2026 09:30
b59a085 to
f3276ac
Compare
frantuma
force-pushed
the
frantuma/types-ramda-dev-dependency
branch
from
October 20, 2026 09:51
f3276ac to
99f4b23
Compare
The published declaration files reference no Ramda types, so consumers never needed @types/ramda, yet every install pulled it in with types-ramda and ts-toolbelt. A dependency policy scan reports @types/ramda and types-ramda as a types package among the runtime dependencies. The package now only needs them to type-check its own sources.
With `@types/ramda` a devDependency, a consumer of the packed package installs neither it nor the `types-ramda` and `ts-toolbelt` it brought in. The policy scan flagged the first two as a types package among the runtime dependencies, and `ts-toolbelt@9.6.0` is older than five years, so the deny-list of the package contract check now includes all three.
frantuma
force-pushed
the
frantuma/types-ramda-dev-dependency
branch
from
October 20, 2026 10:53
99f4b23 to
5b1d1b5
Compare
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.
This is part of the plan to clear the dependency policy findings on the published package. It is independent of the other steps, so it branches from
main.The dependency policy scan reports
@types/ramdaandtypes-ramdaas a types package among the runtime dependencies, and recommends moving it todevDependenciesunless the published.d.tsfiles reference Ramda types. They do not: afternpm run build, nothing undertypes/mentionsramda,types-ramdaorts-toolbelt. Consumers therefore never needed these packages, yet every install pulled in@types/ramda,types-ramdaandts-toolbelt. They now leave the production tree, and the package keeps@types/ramdaonly to type-check its own sources.Since #80 merged first, a second commit adds all three to the deny-list of the package contract check, so they cannot come back into a consumer's install through any dependency.
ts-toolbelt@9.6.0is older than five years, and the plan expected it to leave the tree with this change.Testing
Rebased onto
mainafter #78 and #80. The only conflict was thedevDependenciesblock, andnpm install --package-lock-onlyleaves the resolved lockfile unchanged.npm run build, lint, type-check andnpm test(570 tests) pass, as do the identifier check and the validator drift check../scripts/check-package-contract.shpasses; it installs the packed tarball into a scratch consumer, without@types/ramda, and type-checks every advertised subpath there. Its probe fails on a consumer of the tarball packed before this change, naming@types/ramda,types-ramdaandts-toolbeltwith the paths that bring them in.