Skip to content

feat(cli-v3): expose ./internal subpath for programmatic build/deploy#19

Open
ConProgramming wants to merge 2 commits into
mainfrom
upstream-pr/cli-v3-internal-subpath
Open

feat(cli-v3): expose ./internal subpath for programmatic build/deploy#19
ConProgramming wants to merge 2 commits into
mainfrom
upstream-pr/cli-v3-internal-subpath

Conversation

@ConProgramming
Copy link
Copy Markdown

Summary

Adds the ./internal subpath export to packages/cli-v3 (mirrors @trigger.dev/build's existing ./internal pattern) so external tooling can drive build and deploy programmatically without shelling out to the trigger binary.

11 named exports across build/deploy primitives, auth + project resolution, deploy-time env sync, and build-host helpers. Each one wraps a helper that the cli-v3 commands already use internally — this PR just makes them importable from a stable subpath.

Why

We discovered this while building a custom multi-stage tasks-image build pipeline for an air-gapped environment. The pipeline needs to call loadConfigbuildWorkerbuildImage directly, then later (in a separate pod) call logingetProjectClient → various deployment-API methods. Doing that via the trigger CLI binary requires shelling out, parsing exit codes, etc. Importing from trigger.dev/internal is much cleaner.

Stability

Each export wraps an existing internal helper. The subpath is documented as "consumers should pin to a specific cli-v3 version — the surface sits below the CLI command boundary, signatures may change." Adopters opt into the semver liability explicitly.

Test plan

  • pnpm typecheck passes
  • Existing cli-v3 tests pass
  • pnpm pack produces a tarball with dist/esm/internal.js present
  • Confirmed import { loadConfig } from 'trigger.dev/internal' resolves correctly in a downstream consumer

Notes

Made with Cursor

ConProgramming and others added 2 commits May 26, 2026 11:25
Lets external tooling (CI scripts, custom build orchestrators) drive
the cli-v3 build and deploy flow programmatically without shelling out
to the `trigger` binary or pinning to internal-path imports.

11 named exports covering the four use cases:

  Build/deploy:
    - loadConfig, buildWorker, buildImage, parseGenerateOptions
  Auth + project-environment resolution:
    - login, getProjectClient
  Deploy-time env sync:
    - syncEnvVarsWithServer
  Build-host helpers:
    - resolveLocalEnvVars, loadDotEnvVars, createGitMeta, getTmpDir

Consumers should pin to a specific cli-v3 version — the subpath sits
*below* the documented CLI command surface, so signatures may change.

Mirrors @trigger.dev/build's ./internal subpath pattern.

Co-authored-by: Cursor <cursoragent@cursor.com>
`parseGenerateOptions` was a non-exported module-local helper in
`deploy/buildImage.ts`. The `./internal` subpath re-exports it (it's
the helper that turns `GenerateContainerfileOptions` into the build
args / environment block of a generated Containerfile), so it needs
to be `export`ed at the source.

No behavior change — only the visibility modifier flips.

Co-authored-by: Cursor <cursoragent@cursor.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant