Conversation
…trings Follow-up to #124, applying the same defensive pattern to the rest of validateCliOptions and the providedValues construction in initConfig: - domain, email, apiPath, protocol, authType: type-check before calling string methods (trim/startsWith/toLowerCase/includes), so non-string truthy inputs (e.g. numeric values from programmatic callers) surface a clean validation error instead of a TypeError - The early authType normalization in initConfig (`.trim().toLowerCase()` before validateCliOptions runs) is also guarded so the crash cannot occur before validation gets a chance to report it - Adds regression tests covering domain, apiPath, protocol, and authType
|
🎉 This PR is included in version 2.0.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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
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.
Description
Follow-up to #124. The previous PR fixed
--tokenand--cookieagainst the same crash, but the same pattern (truthy gate, then unguarded string method) lived on for the rest ofvalidateCliOptionsand one earlier-running line ininitConfig. This PR applies the established type-guard pattern uniformly so non-string values from programmatic callers surface a clean validation error instead of aTypeError.What changes
In
lib/config.js:--domain,--email: type-check before.trim()--api-path: type-check before.startsWith('/')--protocol,--auth-type: type-check before.toLowerCase()normAuthTypecalculation: only callnormalizeAuthTypewhen authType is a non-empty string (otherwise the helper itself crashes on numeric input)initConfig's upfrontauthType.trim().toLowerCase()(which runs beforevalidateCliOptions) is also guarded — without this, the crash would happen before validation could surface itWhat was caught during review
While writing tests for the above, the
--auth-typetest exposed exactly the early-crash issue at lib/config.js:517. Without the second fix, the auth-type validation error would never be reachable. Test was added first, fix derived from the failure.Type of Change
Testing
npm test— 350/350 pass (4 new regression tests added: non-string domain / api-path / protocol / auth-type)npm run lint— cleanChecklist
Additional Context
Behavior for valid string inputs is unchanged. Null/undefined are still treated as "not provided" (consistent with the rest of the function). The only observable difference is: numeric/object/etc. inputs that previously crashed with
TypeErrornow produce the matchingcannot be empty/must be ...validation error.