[BUG]: Plugin load failure surfaces as expected dataType to be set assertion instead of the actual error

[schalkneethling]

varlock version

0.9.0

Steps to reproduce

Summary

When @varlock/1password-plugin fails to load (in my case due to a version mismatch with varlock core), schema resolution continues and eventually trips an internal assertion at ConfigItem.resolve with Error: expected dataType to be set. The original plugin load error is never surfaced, which makes the real cause very hard to find.

Separately, the two published plugin packages I use declare peer ranges that don't include varlock@0.8.x or 0.9.x, so a fresh install of varlock@latest alongside the plugins produces a broken combination by default.

Environment

• varlock@0.9.0
• @varlock/1password-plugin@0.2.1 (initially) / 0.3.5 (after update)
• @varlock/vite-integration@0.2.10
• Node.js 24.15.0
• pnpm 10.33.0
• Reproduced both locally (macOS) and on Netlify CI

Reproduction

.env.schema:

# @defaultRequired=infer @defaultSensitive=false
# @generateTypes(lang=ts, path=env.d.ts)
# @plugin(@varlock/1password-plugin)
# @initOp(allowAppAuth=true, account=A1B2C3D4E5F6G7H8)
# ---

# @type=url(startsWith=libsql://) @required
TURSO_DATABASE_URL=op(op://dev/my-db/db-url)

# @sensitive @required
TURSO_AUTH_TOKEN=op(op://dev/my-db/auth-token)

With varlock@0.9.0 + @varlock/1password-plugin@0.2.1, run npx varlock load.

What is expected?

Expected behaviour

When plugin loading fails, varlock should surface that error at the point of failure and halt, rather than continuing into resolution where an internal invariant trips with no context.

The plugin loadPluginModuleCJS path attempting new Function(...) on module source that contains ESM import statements suggests the loader is choosing the wrong module format branch for the plugin's published artifact. Whatever the right fix is there (detection, both-format support, clearer error), the downstream assertion at ConfigItem.resolve should not be the user's first signal.

Root cause (for the case I hit)

Peer-range drift between core and plugins:

• varlock@0.9.0 is the latest core
• @varlock/1password-plugin@0.3.5 (latest) declares peerDependencies: { varlock: "^0.7.3" }
• @varlock/vite-integration@0.2.10 (latest) declares peerDependencies: { varlock: "^0.7.2" }
• @varlock/1password-plugin@0.2.1 declares peerDependencies: { varlock: "workspace:^" }, which appears to be an unpublished monorepo placeholder that leaked into the npm release

In 0.x, ^0.7.x does not include 0.8.x or 0.9.x by npm convention, so the current "latest of everything" combination is mutually incompatible. Downgrading to varlock@0.7.4 with @varlock/1password-plugin@0.3.5 and @varlock/vite-integration@0.2.10 works cleanly with no peer warnings.

What is actually happening?

Observed behaviour

Two different crashes depending on environment, both rooted in the same failure:

Locally:

🚨 Error encountered while loading .env.schema

Cannot use import statement outside a module

Stack trace:
SyntaxError: Cannot use import statement outside a module
    at new Function (<anonymous>)
    at loadPluginModuleCJS (.../varlock/dist/chunk-C4ITUXON.js:9480:20)
    at VarlockPlugin.executePluginModule (.../varlock/dist/chunk-C4ITUXON.js:9655:9)
    at async registerPluginInGraph (.../varlock/dist/chunk-C4ITUXON.js:9736:3)
    at async processPluginInstallDecorators (.../varlock/dist/chunk-C4ITUXON.js:9968:9)
    ...

On Netlify (same schema, same package versions):

Error: expected dataType to be set
    at ConfigItem.resolve (.../varlock/dist/chunk-C4ITUXON.js:12506:31)
    at async resolveItem (.../varlock/dist/chunk-C4ITUXON.js:8126:9)
💥 Varlock config validation failed 💥

The second trace gives no indication that a plugin failed to load. The user-facing appearance is that schema validation failed, when in reality, no schema validation ever happened because the plugin that registers the op() resolver and its data types never initialised.

System Info

Any additional comments?

Suggestions

1. Surface plugin load failures directly. Wrap loadPluginModuleCJS / executePluginModule so the original error is reported with a clear "failed to load plugin X" message, and halt before resolution begins. That alone would have saved this debugging session.
2. Publish plugin releases with peer ranges that include current core versions. If 0.8 and 0.9 are intended to be compatible with the existing plugins, a no-code plugin republish with widened peers would close the gap.
3. Fix the workspace:^ leak in @varlock/1password-plugin@0.2.1. Probably a deprecation rather than a patch at this point, but worth flagging since anyone still resolving to it will hit exactly this crash.

Happy to test a fix or provide additional detail. Thanks for varlock — the schema-first approach has been a genuine improvement for our project.

[philmillman]

Thank you for the detailed report @schalkneethling! @theoephraim is actually in the midst of improving some related release automation, so we'll get this sorted soon.

[schalkneethling]

Thank you for the detailed report @schalkneethling! @theoephraim is actually in the midst of improving some related release automation, so we'll get this sorted soon.

Thanks so much for the quick reply and the awesome tool!

[theoephraim]

Yeah so I had not realized that in semver v0 has different treatment. The^ operator on any v0 version has the same behaviour as ~

We’ll do a v1 bump on everything which should resolve it going forward.

[schalkneethling]

Yeah so I had not realized that in semver v0 has different treatment. The^ operator on any v0 version has the same behaviour as ~

We’ll do a v1 bump on everything which should resolve it going forward.

Thanks so much!