Repository navigation
fix(deps): update dependency @doist/cli-core to v1.7.2 - #95
Conversation
Picks up two auth fixes: a plaintext credential now stays in plaintext across silent token refresh (Doist/cli-core#155), and Linux hosts with no Secret Service no longer write to the per-session kernel keyring (Doist/todoist-cli#577). Silent refresh now calls setBundle with { preserveStorage: true }, so the two refresh tests assert the third argument.
scottlovegrove
added
the
🚢 Ship
doistbot
left a comment
doistbot
left a comment
There was a problem hiding this comment.
This PR bumps @doist/cli-core from 1.6.0 to 1.7.2, bringing the fix that keeps plaintext credential storage stable across token refreshes, and updates two refresh tests to assert the new preserveStorage argument passed to setBundle. No inline issues were flagged. The lockfile growth (nested @napi-rs/keyring 2.1.2 for cli-core, plus unchanged zod relocations) is expected and consistent with the manifest. One small follow-up to consider separately: aligning the root @napi-rs/keyring optionalDependency pin with cli-core's 2.1.2 would let npm dedupe the two copies. Nice, low-risk change — thanks for the clear PR description and end-to-end test notes.
I also left one optional follow-up note in the details below.
Optional follow-up note (1)
package-lock.json:155: cli-core 1.7.2 now needs @napi-rs/keyring 2.1.2, but package.json still pins 1.3.0 in optionalDependencies, so npm installs both the top-level 1.3.0 tree and this nested 2.1.2 tree (including a second set of @napi-rs/keyring-* platform binaries). Nothing in src/ imports @napi-rs/keyring directly, so that 1.3.0 pin appears to be a leftover hoist for cli-core 1.6.0. Bumping it to 2.1.2 (or removing it) would let npm dedupe to a single copy.
Nothing imports @napi-rs/keyring directly; the 1.3.0 pin came over from the twist-cli bootstrap. With cli-core 1.7.2 requiring 2.1.2, it made npm install a second copy of the module and its platform binaries. cli-core declares the keyring as its own optional dependency, so removing the pin leaves a single 2.1.2 copy.
## [3.7.1](v3.7.0...v3.7.1) (2026-10-24) ### Bug Fixes * **deps:** update dependency @doist/cli-core to v1.7.2 ([#95](#95)) ([37b77f5](37b77f5)), closes [Doist/cli-core#155](Doist/cli-core#155) [Doist/todoist-cli#577](Doist/todoist-cli#577)
|
🎉 This PR is included in version 3.7.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Summary
Bumps
@doist/cli-corefrom 1.6.0 to 1.7.2. This fixestdc auth login --credential-store plaintextonly lasting until the next token refresh (Doist/cli-core#155): the refresh moved the rotated tokens into the OS keychain without warning, so automatedtdcuse broke once the Mac was locked and asleep. It also stops Linux hosts with no Secret Service from writing to the per-session kernel keyring (Doist/todoist-cli#577); undertdc's defaultfallbackpolicy those hosts now get plaintext storage with a warning.The fix was tested end to end against
tdcin Doist/cli-core#157: on cli-core 1.6.0 a forced refresh dropped the plaintext copy andtdc doctorswitched to "via secure-store", and with the fix the rotated tokens stayed in the config.1.7.0 adds the extensions subpath (additive) and 1.7.1 bumps cli-core's internal chalk dependency. Neither needs changes here.
Changes
@doist/cli-core1.6.0 → 1.7.2.auth.test.ts: silent refresh now callssetBundle(account, bundle, { preserveStorage: true }), so the assertions include the third argument.@napi-rs/keyring1.3.0 optional dependency. Nothing imports it (it came over from the twist-cli bootstrap), and with cli-core 1.7.2 requiring 2.1.2 it made npm install a second copy of the module and its platform binaries. cli-core declares the keyring as its own optional dependency, so a single 2.1.2 copy remains.npm also moved the existing
zod@3.25.76from the top level into nested copies under the@jimp/*plugins; the version is unchanged.Test plan
npm run build,npm run type-check,npm run lint:checknpm test@napi-rs/keyring(2.1.2) is left in the lockfile, and cli-core loads it at runtime (createSecureStore().getSecret()on an empty slot returnsnull)