chore(deps): upgrade @pkcprotocol/pkc-js 0.0.83 -> 0.0.85 - #135
Conversation
0.0.85 validates settings.challenges against each challenge file's optionInputs. @bitsocial/mintpass-challenge marks chainTicker, contractAddress and requiredTokenType as required, and `default` in optionInputs is a UI hint that core never applies, so the mintpass integration test's option-less config is now rejected on edit(). Pass the three options explicitly, using the package's own runtime fallbacks so challenge behaviour is unchanged.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe pull request updates ChangesMintpass dependency update
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: 🔵 Low · up to The dependency upgrade is covered by clean builds and 341 passing CLI tests, but existing communities with invalid persisted challenge settings may now log errors on each start and require correction before edits succeed. This is a bounded runtime concern that warrants owner awareness, while the PR remains mergeable with follow-up. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
package.jsonOops! Something went wrong! :( ESLint: 8.27.0 Error: ESLint configuration in --config » eslint-config-oclif is invalid:
Referenced from: /.eslintrc test/cli/mintpass-integration.test.tsESLint skipped: the matched ESLint configuration already failed (config-incompatibility). Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Closes #134
What
Bumps
@pkcprotocol/pkc-jsfrom0.0.83to0.0.85(latest on npm). Lockfile diff touches only pkc-js itself — no transitive dependency changes.Upstream changes
v0.0.84
abortSignal,publication.stop()anddestroy()(feat(pkc): cancel in-flight community fetches via abortSignal, publication.stop() and destroy() pkcprotocol/pkc-js#276)v0.0.85
validateChallengeSettingsand coreoptionInputsvalidation (feat(challenges): add validateChallengeSettings and core optionInputs validation (#283) pkcprotocol/pkc-js#288)The one source change
0.0.85 validates
settings.challenges[]against each challenge file'soptionInputson the edit, community-creation and start paths. That surfaced a genuinely invalid config intest/cli/mintpass-integration.test.ts, which configured the challenge with no options at all:@bitsocial/mintpass-challengedeclareschainTicker,contractAddressandrequiredTokenTypeasrequired: true. In pkc-js,requiredmeans present in settings anddefaultinoptionInputsis a UI hint that core never applies (runtime/node/community/challenges/validate-challenge-settings.js), soedit()now throwsERR_CHALLENGE_REQUIRED_OPTION_MISSING, aggregated intoERR_CHALLENGE_SETTINGS_VALIDATION_FAILED_FOR_CHALLENGES.Fixed by passing the three options explicitly. The values are the package's own runtime fallbacks (
dist/mintpass.js:435destructureschainTicker = "base",requiredTokenType = "0", and falls back toDEFAULT_CONTRACTS[chainTicker]for the address), so challenge behaviour is unchanged — the test was relying on those fallbacks implicitly and now states them.No other call site is affected: the remaining challenges used in tests (
question,test-challenge,captcha-canvas-v3) either declare no requiredoptionInputsor already pass their options.Operational note for existing communities
Worth knowing before this ships to a live daemon: any community whose persisted challenge config has a typo'd/undeclared option key, a missing
requiredoption, or an undeclaredpublicOptionsentry will now emit oneerrorevent per invalid challenge on every start, carrying{challengeIndex, challengeName, communityAddress}. The community still starts — a persisted bad config never takes startup down — but the errors are new and will look like a regression to whoever sees them first. A subsequentcommunity editon such a community will throw until the config is corrected.Verification
npm run build && npm run build:test— cleannpm run test:cli— 43 files, 341 passed, 1 skipped, 0 failedSummary by CodeRabbit