@basenative/doppler

中文文档
3.0.0发布于 2026/10/31Apache-2.0TypeScriptES Module零依赖构建来源已验证

Thin developer-experience layer around Doppler — local-dev wrapper, CI helper, project bootstrap, environment validation. BaseNative ships plumbing, never values.

原始使用文档
文档目录10 节
  1. Boundary rule
  2. Install
  3. One-time project setup
  4. Local dev workflow
  5. CI/CD wiring (GitHub Actions)
  6. bn-doppler verify
  7. Programmatic API
  8. Why this pattern
  9. Links
  10. License

@basenative/doppler

Plumbing, not values. BaseNative gives every project the same Doppler workflow; Doppler holds the actual secrets.

A thin, dependency-free developer-experience layer over the Doppler CLI. Lets every DuganLabs repo (basenative, duganlabs, greenput, pendingbusiness, ralph-station, t4bs, warren-sys, warrendugan) bootstrap, validate, and run through Doppler the exact same way.

Boundary rule

BaseNative provides plumbing only. It never reads, stores, or transmits values.

Every command in this package shells out to doppler for the real work. The CLI exists to make the workflow consistent across projects — not to act as a secrets store of its own.

Install

# Per-project
pnpm add @basenative/doppler

# The doppler CLI is a system dependency, not an npm dep:
brew install dopplerhq/cli/doppler         # macOS
curl -Ls --tlsv1.2 https://cli.doppler.com/install.sh | sh   # Linux
scoop install doppler                       # Windows

doppler login                                # one time

One-time project setup

bn-doppler init my-app

This will:

  1. Create a Doppler project named my-app.
  2. Create configs dev, prep, prod.
  3. Pin the local repo to the dev config (doppler setup).
  4. Drop a starter doppler-required.json into the repo root.

Edit doppler-required.json to declare exactly which secrets the app expects:

{
  "secrets": [
    { "name": "DATABASE_URL",   "required": true },
    { "name": "SESSION_SECRET", "required": true },
    { "name": "SENTRY_DSN",     "required": false }
  ],
  "configs": ["dev", "prep", "prod"]
}

Then set values via the dashboard or CLI:

doppler secrets set DATABASE_URL
doppler secrets set SESSION_SECRET

Local dev workflow

# Recommended in your repo's package.json scripts:
{
  "dev":   "doppler run -- pnpm exec bn-wrangler pages dev dist",
  "build": "doppler run -- pnpm build"
}

# Or via the wrapper:
bn-doppler run -- pnpm dev

That's it. No .env files. No accidental commits of secrets. If a secret is missing, the app gets a fast, specific error at boot via requireSecrets.

CI/CD wiring (GitHub Actions)

# Once, locally:
bn-doppler ci-token --config prod
# (it asks for confirmation, then prints the token)

# Add it to the repo:
gh secret set DOPPLER_TOKEN --body "<paste>"

Then in .github/workflows/deploy.yml (full snippet at templates/.github-actions-doppler-snippet.yml):

- uses: dopplerhq/cli-action@v3

- name: Verify Doppler secrets
  env: { DOPPLER_TOKEN: ${{ secrets.DOPPLER_TOKEN }} }
  run: pnpm exec bn-doppler verify --config prod

- name: Deploy
  env: { DOPPLER_TOKEN: ${{ secrets.DOPPLER_TOKEN }} }
  run: doppler run --config prod -- pnpm exec bn-wrangler deploy

bn-doppler verify

Cross-checks doppler-required.json against the actual Doppler config:

bn-doppler verify --config dev
# OK — all 3 required secret(s) are populated in config "dev".

If anything's missing, it exits non-zero and prints exactly which names are absent — perfect as the first step in CI before deploy.

Programmatic API

import {
  dopplerRun,
  requireSecrets,
  injectIntoWrangler,
  MissingSecretsError,
} from '@basenative/doppler';
import { loadRequired, findMissing } from '@basenative/doppler/required';

// Boot-time check (after `doppler run -- node ./server.js` injects env vars):
await requireSecrets(['DATABASE_URL', 'SESSION_SECRET']);

// Or pull straight from Doppler:
await requireSecrets(['DATABASE_URL'], {
  source: 'doppler',
  project: 'my-app',
  config: 'prod',
});

// Split resolved values into vars vs secrets for Wrangler:
const { vars, secrets } = injectIntoWrangler({
  env: process.env,
  names: ['APP_NAME', 'API_TOKEN', 'SESSION_SECRET'],
});

// Or run a child process under doppler:
await dopplerRun(['pnpm', 'build'], { config: 'prod' });

Why this pattern

  • One playbook for every project. doppler run -- pnpm dev works the same in basenative, t4bs, greenput, etc.
  • No .env drift. Local dev, preview, and prod all read from the same canonical Doppler configs.
  • CI auditability. A single DOPPLER_TOKEN in GitHub instead of 17 individual secrets.
  • Boot-time fail-fast. requireSecrets turns a 3am production page into a 9am red CI run.
  • No values in BaseNative. This package is plumbing — every actual secret lives in Doppler, end of story.

License

Apache-2.0

版本与发布记录

@basenative/doppler 共发布 11 个版本,首次发布于 2026/10/18;过去 12 个月发布了 11 个版本。最新版本附带 npm provenance 构建来源证明,可追溯到公开的 CI 构建记录。

版本发布日期距今
3.0.0latest2026/10/312 天前
2.4.02026/10/268 天前
2.3.22026/10/2212 天前
2.3.12026/10/2212 天前
2.3.02026/10/2212 天前
2.2.02026/10/2113 天前

关于 @basenative/doppler 的常见问题

@basenative/doppler 是什么?

围绕多普勒的瘦开发人员体验层-本地开发包装器,CI助手,项目引导,环境验证。BaseNative ship plumbing, never values。

如何安装 @basenative/doppler?

在项目目录运行 npm install @basenative/doppler,或使用 pnpm add / yarn add / bun add。它还提供命令行工具 bn-doppler,可以用 npx bn-doppler 直接运行。

@basenative/doppler 支持 TypeScript 吗?

支持。包内自带 TypeScript 类型声明(package.json 声明了 types 入口),安装后即可获得类型提示,无需再安装 @types 包。

@basenative/doppler 支持 ESM 还是 CommonJS?

以 ES Module 形式发布,推荐使用 import 引入。在 CommonJS 项目中,Node.js 20.19+ / 22.12+ 可以直接 require() 不含顶层 await 的 ES Module,更早的版本需要改用动态 import()。

@basenative/doppler 可以商用吗?

@basenative/doppler 使用 Apache-2.0 许可。宽松许可:允许商业使用、修改和再分发,并附带明确的专利授权;分发时需保留许可与 NOTICE 文件,修改过的文件要注明改动。以上为概括,不构成法律意见,请以许可原文为准。

@basenative/doppler 还在维护吗?

最新版本 3.0.0 发布于 2026/10/31(2 天前);至今共发布 11 个版本,其中过去 12 个月发布了 11 个;首次发布于 2026/10/18。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。