Skip to content

run: program importing Drive via relative source path fails with missing default-config.jsonc #77

Description

@kitlangton

Drive c2bfef2 (packages/drive), Bun 1.4.0, OpenCode V2 36095decd7.

A one-shot program passed to drive run that imports Drive from source (import { Llm, OpenCodeDriver } from "../src/index.js", as a scratch script under packages/drive/.drive-output/ would) type-checks fine and then fails at instance initialization:

error: ENOENT: no such file or directory, open '/private/var/folders/.../opencode-drive-run-92qgPu/script-runtime/compiled/default-config.jsonc'
      _tag: "OpenCodeDriverError",
 operation: "project.initialize",

src/instance/instance.ts reads new URL("./default-config.jsonc", import.meta.url), which resolves relative to the compiled bundle in the run's script-runtime/compiled/ directory; the bundle step does not copy the asset. Switching the import to the package name (from "opencode-drive") works, so the workaround is trivial, but the failure surfaces as a project-initialize ENOENT rather than pointing at the import.

Expected: either the compile step carries default-config.jsonc (or inlines it), or run/check rejects a relative Drive source import with a message that names the fix.

Activity

  1. kitlangton commented on Sep 3, 2026

    @kitlangton
    ContributorAuthor

    Related source-import failure on Drive 2.0.1 (source f6a3f55), Bun 1.4.0, testing OpenCode efefd90443: running an external script through the installed CLI while importing Drive or client schemas from another checkout produced a large typecheck cascade before launch. Both Effect installations reported 4.0.0-rc.112, but errors included NodeInspectSymbol identity and SchemaAST private _rebuild identity mismatches.

    Recovery was to invoke the source CLI, import opencode-drive by package name, and use the client schemas from that same CLI installation. The unchanged scenario then ran successfully. A focused diagnostic explaining the mixed module roots would be much clearer than the cascading errors.

  2. kitlangton commented on Sep 5, 2026

    @kitlangton
    ContributorAuthor

    The same relocation issue affects user-owned fixtures in Drive 2.1.0, even with the package-name import. A one-shot Effect program reading Bun.file(new URL("./fixture.txt", import.meta.url)) fails because run moves the compiled module into script-runtime/compiled/ without copying fixture.txt.

    Observed before server launch with Bun 1.4.0 while preparing a demo for OpenCode V2 97303c39dd153b64d7036249b279490201820b19. The error was ENOENT ... script-runtime/compiled/fixture.txt. Reading the fixture relative to a deliberately fixed runner working directory works. It would help to preserve relative assets, or document that import.meta.url no longer points at the submitted source module.

  3. kitlangton commented on Sep 6, 2026

    @kitlangton
    ContributorAuthor

    Reproduced with Drive 2.1.0 and Bun 1.4.0 while preparing an isolated OpenCode V2 cd504dc66a regression demo. An absolute import of the Drive source entrypoint also produces the relocated script-runtime/compiled/default-config.jsonc ENOENT. The installed CLI additionally produced the same mixed-Effect identity cascade noted above. Using the source CLI and the opencode-drive package-name import gets past both failures.

  4. kitlangton commented on Sep 19, 2026

    @kitlangton
    ContributorAuthor

    Fixed by #100. The isolated default configuration is now bundled as TypeScript data, so source-imported drive run programs no longer lose the JSONC asset.

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

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions