fix(release): bump a patch for build(deps) commits - #46
Merged
Merged
Conversation
Three security patches (#37, #38, #43, #44, #45) landed as build(deps): commits and never reached npm: the changelog preset marks build as effect: "changelog", so release-it correctly found nothing to release and exited 0 every time. Nobody was watching for that, so the patches sat on master. findTypeEntry matches on type and scope before falling back to the scope-less entry, so a build(deps) entry ahead of the generic build one in TYPES lets dependency and security patches bump a patch while scope-less build: (tooling, tsconfig, oxfmt) still doesn't move the version. changelog-check.mjs's POLICY and assertions are updated to match, including a build(deps) vs build bump test so this can't regress silently again.
bb07d7b fixed the SDK 53+ AppDelegate.swift bundle URL redirect back in v1.0.13, but the SDK-support note above it was written 26 minutes earlier the same day and never got updated. Confirmed by prebuild against a fresh SDK 57 app: CodePush.bundleURL() lands in ReactNativeDelegate.bundleURL() same as the Objective-C template does.
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.
Summary
build(deps):commits never bump a release, so the three security patches that landed that way (#37, #38, #43, #44, #45) sat on master and never reached npm. This makesbuild(deps)bump a patch like any other dependency fix.Details
tools/changelog-preset.mjs: added a{ type: "build", scope: "deps", effect: "bump" }entry ahead of the genericbuildentry.findTypeEntry(inconventional-changelog-conventionalcommits) matches type+scope before falling back to the scope-less one, sobuild(deps):now bumps a patch while a scope-lessbuild:(tsconfig, oxfmt, tooling) still doesn't move the version.chore(deps):stays changelog-only, matching how it's actually used here (release-age policy, allowing magic-* through).tools/changelog-check.mjs:POLICYnow takestype:scopekeys so it can tellbuildandbuild:depsapart, plus a bump assertion (build(deps)-> patch, scope-lessbuild-> no bump). Dry-run proof below shows the three backlogged patches actually rendering under av2.0.1release now.README.md: the SDK-support note said the plugin "does not yet touch the SwiftAppDelegate" on SDK 52+. That fix landed in v1.0.13 (iOS AppDelegate mod does nothing on Expo SDK 53+ and does not say so聽#30) and the note was never updated. Confirmed working prebuild against a fresh SDK 57 app and corrected the note.I also checked the two things Gabriel flagged separately:
pnpm auditis clean (the two flagged advisories areimage-size, already patched locally and exercised bydependency-security-check.mjs), and the v1.0.14 -> v2.0.0 breaking change already renders correctly in bothCHANGELOG.mdand the GitHub release body, so no fix needed there.One correction to flag: this package has no
dependencies, onlydevDependenciesand a peer onexpo.xmldom,js-yaml,nanoidandimage-sizeonly ever reach this repo's own dev/build/CI tree (throughexpo's own tooling) via thepnpm-workspace.yamloverrides, not the published tarball. So the three backlogged patches harden this repo's own supply chain, not something a consumer'snpm installwas pulling in vulnerable. Still worth shipping for the changelog record and because the process gap is real regardless of blast radius.Proof (dry-run release output, test suite, changelog check, security audit, and the prebuild verification against a fresh SDK 57 app):
Testing steps
This is a config-plugin release pipeline fix with no UI, so there's nothing to click through. The proof links above are the testing steps: the dry-run log shows
release-itinferring2.0.0 -> 2.0.1with all three backloggedbuild(deps)patches in the changelog, and the prebuild log shows a real Expo SDK 57 app getting the Android gradle/manifest and iOS Info.plist/AppDelegate changes after installing the plugin.After this merges, dispatching the Release workflow on master with no
incrementoverride should cut v2.0.1 and publish it.Post-merge: dispatched the Release workflow on master. v2.0.1 is live on npm (
npm view react-native-code-push-plugin version->2.0.1, registrydist-tags.latest->2.0.1), the v2.0.1 GitHub release lists the three backlogged patches, and #47 (the version-bump PR) merged. Re-ran the prebuild check against the actual published2.0.1tarball installed from the registry (not the local build) on the same fresh SDK 57 app, same result: