Skip to content

cdktn-cli: Invoke Terraform CLI with node:child_process instead of node-pty. (Bun + Deno support) #4

New issue
New issue
Closed
#55
Closed
cdktn-cli: Invoke Terraform CLI with node:child_process instead of node-pty. (Bun + Deno support)#4
#55
Labels
enhancementNew feature or request

Description

@commiterate
commiterate
opened on Jan 13, 2026

Description

See hashicorp/terraform-cdk#3675.

This should heavily reduce maintenance requirements by dropping node-pty (has native components. CDKTF maintained a fork to pre-compile for 200+ platforms) in favor of node:child_process.

Help Wanted

  • I'm interested in contributing a fix myself

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Activity

  1. commiterate
    added
    enhancementNew feature or request
    on Jan 13, 2026

  2. so0k commented on Jan 13, 2026

    @so0k
    so0k
    on Jan 13, 2026 · Hidden as resolved
  3. commiterate
    changed the title [-]`cdktf-cli`: Invoke Terraform CLI with `node:child_process` instead of `node-pty`. (Bun + Deno support)[/-] [+]`cdktn-cli`: Invoke Terraform CLI with `node:child_process` instead of `node-pty`. (Bun + Deno support)[/+] on Jan 13, 2026

  4. jsteinich commented on Mar 5, 2026

    @jsteinich
    jsteinich
    on Mar 5, 2026
    Contributor

    I traced back the addition of node-pty to hashicorp/terraform-cdk#1955.

    hashicorp/terraform-cdk#1955 (comment) in particular mentions needed to have an interactive session with the terraform cli for accessing Terraform Cloud.

    The pre-built version was added with the same PR with a note of needing to add it for Windows support.

    There was some mention of possible changes to Terraform itself to provide better support. Should investigate that further since perhaps a PTY/TTY terminal is no longer required. If it is still required, moving away could be rather challenging.

  5. so0k commented on Mar 5, 2026

    @so0k
    so0k
    on Mar 5, 2026
    Contributor

    we could also consider TerraConstructs/terraform-cdk#5 (comment)

    use the maintained @homebridge/node-pty-prebuilt-multiarch

    or see if opentofu has these issues 😁

  6. commiterate commented on Mar 5, 2026

    @commiterate
    commiterate
    on Mar 5, 2026
    Author

    The originating CDKTF issue I linked notes that node:child_process.spawn() has a stdio: 'inherit' option which seems like it lets a Node.js process control an interactive child process (e.g. Terraform/OpenTofu CLI).

    Ideally cdk-terrain could do something like this:

    // Works with Node.js or any runtime with Node.js polyfills (e.g. Bun, Deno).
import { spawn } from "node:child_process";

/*
    https://developer.hashicorp.com/terraform/cdktf/create-and-deploy/environment-variables

    Default to 'opentofu' or 'terraform' if not specified.
*/
tf_binary_name = process.env.TERRAFORM_BINARY_NAME || 'opentofu';

spawn(tf_binary_name, [ 'apply' ], { stdio: 'inherit' });
// Wait for confirmation prompt on stdout...
process.stdin.write('yes\n');

    Dropping node-pty-prebuilt-multiarch isn't just about not maintaining pre-built binaries.

    Pre-built binaries are fundamentally a bad experience with things like mismatched C standard library versions (glibc, musl) and hardcoded dynamic linker paths (painful on some operating systems like NixOS and Guix).

    The original CDKTF issue elaborates on this much further.

  7. so0k
    closed this as completedin #55on Apr 1, 2026

  8. so0k commented on Apr 2, 2026

    @so0k
    so0k
    on Apr 2, 2026
    Contributor

    this is merged and released in this tag @commiterate https://www.npmjs.com/package/cdktn/v/0.23.0-pre.15 if anyone wants to test it?

  9. commiterate commented on Apr 5, 2026

    @commiterate
    commiterate
    on Apr 5, 2026
    Author

    @so0k commiterate/test-cdktn-bun@617135a

    This is using a minimal Nix shell in the nixos/nix container (see the readme for details).

    $ just build
# Install JavaScript dependencies.
bun install
bun install v1.3.8 (b64edcb4)

+ @tsconfig/bun@1.0.10
+ @tsconfig/strictest@2.0.8
+ @types/node@22.19.15
+ cdktn-cli@0.23.0-pre.17
+ typescript@5.9.3
+ @cdktn/provider-aws@23.6.0
+ cdktn@0.23.0-pre.17
+ confbox@0.2.4
+ constructs@10.6.0

787 packages installed [15.53s]
# Format.
if [[ -z "${CI:-}" ]]; then treefmt; else treefmt --fail-on-change; fi
traversed 27 files
emitted 17 files for processing
formatted 0 files (0 changed) in 13ms
# Lint JavaScript files.
if [[ -z "${CI:-}" ]]; then oxlint --fix; else oxlint; fi

  ⚠ eslint-plugin-unicorn(no-empty-file): Empty files are not allowed.
   ╭─[src/[service]/[stage].ts:1:1]
 1 │ // ⛔ There should be no stage stratum resources.
   · ──────────────────────────────────────────────────
   ╰────
  help: Delete this file or add some code to it.

Found 1 warning and 0 errors.
Finished in 28ms on 6 files with 90 rules using 12 threads.
# Type check JavaScript files.
bun run tsc
# Remove build artifacts.
rm -rf build
# Synthesize templates.
bun run cdktn synthesize --quiet
Could not run version check - Command failed: npm view cdktf-cli version
/bin/sh: line 1: npm: command not found

Usage Error: Node.js version could not be determined
error: "cdktn" exited with code 1
error: Recipe `synthesize` failed on line 30 with exit code 1

    I think this is from https://github.com/open-constructs/cdk-terrain/blob/v0.23.0-pre.17/packages/cdktn-cli/src/bin/cmds/helper/check-environment.ts#L53-L56.

    DISABLE_VERSION_CHECK=true (i.e. DISABLE_VERSION_CHECK=true bun run cdktn synthesize --quiet) doesn't seem to fix it either since that's for library version checks.

    $ just build
# Install JavaScript dependencies.
bun install
bun install v1.3.8 (b64edcb4)

Checked 396 installs across 397 packages (no changes) [68.00ms]
# Format.
if [[ -z "${CI:-}" ]]; then treefmt; else treefmt --fail-on-change; fi
traversed 27 files
emitted 17 files for processing
formatted 0 files (0 changed) in 18ms
# Lint JavaScript files.
if [[ -z "${CI:-}" ]]; then oxlint --fix; else oxlint; fi

  ⚠ eslint-plugin-unicorn(no-empty-file): Empty files are not allowed.
   ╭─[src/[service]/[stage].ts:1:1]
 1 │ // ⛔ There should be no stage stratum resources.
   · ──────────────────────────────────────────────────
   ╰────
  help: Delete this file or add some code to it.

Found 1 warning and 0 errors.
Finished in 23ms on 6 files with 90 rules using 12 threads.
# Type check JavaScript files.
bun run tsc
# Remove build artifacts.
rm -rf build
# Synthesize templates.
DISABLE_VERSION_CHECK=true bun run cdktn synthesize --quiet
Usage Error: Node.js version could not be determined
error: "cdktn" exited with code 1
error: Recipe `synthesize` failed on line 30 with exit code 1

    IMO these runtime and library version checks shouldn't exist to begin with. That information is supposed to be in any package dependency declarations (e.g. engines + dependencies in package.json, requires-python + dependencies in pyproject.toml, maven.compiler.target + maven.compiler.source + dependencies in pom.xml) and enforced by package managers.

  10. commiterate commented on Apr 12, 2026

    @commiterate
    commiterate
    on Apr 12, 2026
    Author

    @so0k Should we open a separate issues for the remaining Node.js dependencies and version checks?

  11. jsteinich commented on Apr 14, 2026

    @jsteinich
    jsteinich
    on Apr 14, 2026
    Contributor

    @so0k Should we open a separate issues for the remaining Node.js dependencies and version checks?

    @commiterate we should definitely make a separate issue for tracking making compatible with alternative runtimes.

  12. commiterate commented on Apr 14, 2026

    @commiterate
    commiterate
    on Apr 14, 2026
    Author

    Done: #106

  13. github-actions commented on May 14, 2026

    @github-actions
    github-actionsBot
    on May 14, 2026 – with GitHub Actions
    Contributor

    I'm going to lock this issue because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

  14. github-actions
    locked as resolved and limited conversation to collaborators on May 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions