windmill-labs/windmill · warning

Could not generate tsconfig: ${error instanceof Error ? erro

Error message

Could not generate tsconfig: ${error instanceof Error ? error.message : error}

What it means

After `wmill init` writes wmill.yaml, it generates a managed TypeScript tsconfig (tsconfig.wmill.json plus a user tsconfig.json extending it) via refreshTsconfig. Any error thrown by that purely local generation step is caught and logged as this warning; init continues without the IDE tsconfig.

Source

Thrown at cli/src/commands/init/init.ts:247

          }
        }
      } catch (error) {
        log.warn(
          `Could not check backend for git-sync settings: ${(error as Error).message}`
        );
        log.info("Continuing with default settings");
      }
    }
  }

  await refreshPrompts({ yes: opts.useDefault === true });

  // Generate the IDE tsconfig (managed tsconfig.wmill.json + user tsconfig.json
  // that extends it). Independent of any workspace binding — it's purely local.
  try {
    await refreshTsconfig({ yes: opts.useDefault === true });
  } catch (error) {
    log.warn(
      `Could not generate tsconfig: ${
        error instanceof Error ? error.message : error
      }`
    );
  }

  // Generate resource type namespace (needs a bound workspace)
  if (didBindWorkspace && boundProfile) {
    try {
      // Cache the bound profile so resolveWorkspace doesn't re-resolve and prompt again
      const rtOpts = { ...opts } as GlobalOptions;
      (rtOpts as any).__secret_workspace = boundProfile;
      await generateRTNamespace(rtOpts);
    } catch (error) {
      log.warn(
        `Could not pull resource types and generate TypeScript namespace: ${
          error instanceof Error ? error.message : error
        }`

View on GitHub (pinned to e474e8803c)

Solutions

  1. Check write permissions on the project root (where wmill.yaml was created) and re-run `wmill init`.
  2. If a managed tsconfig already exists, delete tsconfig.wmill.json and re-run, or manually keep your tsconfig.json extending tsconfig.wmill.json.
  3. Use `wmill init --use-default` so refreshTsconfig runs non-interactively with yes=true (avoids interactive-confirm failures in CI).
  4. Read the warning text for the concrete cause (EACCES/EPERM => permissions; ENOTDIR => wrong working directory).

Example fix

// before
wmill init   # in a CI job, fails to confirm tsconfig overwrite
// after
wmill init --use-default
Defensive patterns

Strategy: try-catch

Validate before calling

import { stat } from "node:fs/promises";
// confirm the project root is writable before running init
try {
  await stat(".");
  await writeFile(".write-test", "");
  await rm(".write-test");
} catch (e) {
  console.error("project directory is not writable:", e);
}

Type guard

function toErrorMessage(error: unknown): string {
  return error instanceof Error ? error.message : String(error);
}

Try / catch

try {
  await refreshTsconfig({ yes: true });
} catch (error) {
  log.warn(`Could not generate tsconfig: ${toErrorMessage(error)}`);
}

Prevention

When it happens

Trigger: Calling `wmill init` when refreshTsconfig fails — typically a filesystem error writing tsconfig.wmill.json/tsconfig.json (read-only directory, permission denied, existing tsconfig.json that cannot be updated without confirmation) or an error composing the config from the current directory state.

Common situations: Running init in a read-only mount or directory owned by another user; existing tsconfig.json with restrictive permissions; running init non-interactively (CI) where refreshTsconfig would prompt for confirmation but opts.useDefault is false and no TTY is available.

Understand the failure class

Background: "failed to write file", "Could not save figure", "Error saving remote file" — file write failed: causes and fixes across languages and libraries — this error's family across 38 libraries.

Related errors


AI-assisted analysis of windmill-labs/windmill@e474e8803c (2026-09-03). Data as JSON: /api/errors/c9ce46cb4a3d55cd. Report an issue: GitHub.