chore(deps): bump croner from 9.0.0 to 10.0.1 - #48
Conversation
dependabot
Bot
added
dependencies
tps-kern
left a comment
tps-kern
left a comment
There was a problem hiding this comment.
Architecture Review — REQUEST_CHANGES ❌
Major bump: croner 9.0.0 → 10.0.1 in packages/shell.
CI: Build FAILURE, Dependency Audit FAILURE, Unit Tests SKIPPED.
This is a MAJOR version with documented breaking changes:
?character now acts as wildcard alias (same as*) per OCPS 1.4, instead of substituting current time values. If bob uses?in any cron patterns, behavior WILL change.- Stricter range parsing by default — may reject previously-valid patterns unless
sloppyRanges: trueis set. - Minimum Deno version increased to 2.0 (not relevant for Node/Bun, but indicates significant internal changes).
Action required:
- Check CI build logs for the specific failure — likely a type-level break from the API changes.
- Audit all cron patterns in bob's codebase for
?usage — if any exist, they will silently change behavior (wildcard instead of current-time substitution). - If patterns use
?, either migrate them to explicit values or setsloppyRanges: true. - Re-run CI after any fixes. Do not merge with red CI and unverified cron behavior.
tps-kern
left a comment
tps-kern
left a comment
There was a problem hiding this comment.
Architecture review — REQUEST_CHANGES (lockfile not regenerated).
Diff: 1 line in packages/shell/package.json, bumping croner from 9.0.0 to 10.0.1. This is a major version bump (9→10). No code changes.
Breaking changes in croner 10.0.0: The ? character now acts as a wildcard alias (same as *) per OCPS 1.4 instead of substituting current time values. Stricter range parsing by default (use sloppyRanges: true for legacy behavior). Minimum Deno version increased to 2.0 (irrelevant — bob uses Bun, not Deno). The legacyMode option was renamed to domAndDow (backward compatible — legacyMode still works).
Architecture concern: croner is used by the packages/shell package for cron scheduling. The ? wildcard behavior change is the primary risk — if any cron patterns in the codebase use ? expecting the old "substitute current time" semantics, they will now behave as * (match-all). This would be a silent behavior change. The team should audit all cron patterns for ? usage before merging. If no patterns use ?, this is safe.
CI failure: Both Build (TypeScript strict) and Dependency Audit fail with:
error: lockfile had changes, but lockfile is frozen
The lockfile is configured as frozen/immutable, but bumping the dependency requires a lockfile regeneration. Someone needs to run bun install on the branch and commit the updated lockfile before CI will pass.
Action needed:
- Audit all cron patterns in the codebase for
?usage — confirm none rely on the old "substitute current time" semantics. - Run
bun installon the branch and commit the regenerated lockfile. - Re-request review after CI is green.
tps-sherlock
left a comment
tps-sherlock
left a comment
There was a problem hiding this comment.
Security Review — REQUEST_CHANGES ❌
CI is red — blocking
- Build (TypeScript strict): FAILURE —
error: lockfile had changes, but lockfile is frozen - Dependency Audit: FAILURE — same root cause
- Unit Tests: SKIPPED — blocked by build failure
The lockfile is frozen/immutable. bun install must be run on the branch and the regenerated lockfile committed before CI can pass.
Security concern: ? wildcard behavior change
croner 10.0.0 changed the ? character from "substitute current time values" to a wildcard alias (same as *) per OCPS 1.4. If any cron patterns in bob's codebase use ?, they will silently change from time-substitution to match-all. This is a scheduling integrity risk — tasks could fire at unintended times, including during maintenance windows or outside expected bounds.
Required before approval:
- Audit all cron patterns in the codebase for
?usage — confirm none rely on the old time-substitution semantics - If
?is used, either migrate to explicit values or setsloppyRanges: true - Run
bun installand commit the regenerated lockfile - CI must be all green (Build, Audit, Tests)
Supply chain — clean
Socket Security, CodeQL all pass. No known CVEs in croner 10.0.1.
Diff scope
Single line in packages/shell/package.json — croner: "9.0.0" → "10.0.1". No code changes. The risk is entirely in the breaking API changes and the frozen lockfile.
|
@dependabot recreate |
Bumps [croner](https://github.com/hexagon/croner) from 9.0.0 to 10.0.1. - [Release notes](https://github.com/hexagon/croner/releases) - [Changelog](https://github.com/Hexagon/croner/blob/master/CHANGELOG.md) - [Commits](Hexagon/croner@9.0.0...10.0.1) --- updated-dependencies: - dependency-name: croner dependency-version: 10.0.1 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
cb3f38c to
166e075
Compare
|
Closing as superseded by #109. This PR touches That difference is the whole reason this one was never mergeable. CI runs This was never a bad bump. It was the only shape dependabot could produce while misconfigured as an npm project — see #103. Nothing here needed fixing; the config did. #109 proposes the same change correctly. Review that one instead. |
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
3 participants
Bumps croner from 9.0.0 to 10.0.1.
Release notes
Sourced from croner's releases.
... (truncated)
Changelog
Sourced from croner's changelog.
... (truncated)
Commits
adc8621Fix dist structure and bump to 10.0.1 (#342)d3f013bCleanup of README (#341)e894e4aMerge pull request #339 from Hexagon/devd381fd9Fix test assertions checking cron instance nullability instead of next run ex...8914d77Review and prepare Croner 10.0.0 for release (#326)8478bf6Add PayPal and GitHub Sponsors funding info to package.json (#338)72c6d00Update version from 10.0.0-dev.7 to 10.0.0-dev.8005adfbFix cron job stopping when catch callback throws with protect enabled (#337)be285ddDocument getOnce() and previousRuns() features, bump to 10.0.0-dev.7 (#333)f8b708bFix getPattern() returning wrong value for date-based jobs (#331)