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
- 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.
- 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.
- 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.
varlock version
0.9.0
Steps to reproduce
Summary
When
@varlock/1password-pluginfails to load (in my case due to a version mismatch withvarlockcore), schema resolution continues and eventually trips an internal assertion atConfigItem.resolvewithError: 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.xor0.9.x, so a fresh install ofvarlock@latestalongside 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.10Reproduction
.env.schema:With
varlock@0.9.0+@varlock/1password-plugin@0.2.1, runnpx 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
loadPluginModuleCJSpath attemptingnew Function(...)on module source that contains ESMimportstatements 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 atConfigItem.resolveshould not be the user's first signal.Root cause (for the case I hit)
Peer-range drift between core and plugins:
varlock@0.9.0is the latest core@varlock/1password-plugin@0.3.5(latest) declarespeerDependencies: { varlock: "^0.7.3" }@varlock/vite-integration@0.2.10(latest) declarespeerDependencies: { varlock: "^0.7.2" }@varlock/1password-plugin@0.2.1declarespeerDependencies: { varlock: "workspace:^" }, which appears to be an unpublished monorepo placeholder that leaked into the npm releaseIn 0.x,
^0.7.xdoes not include0.8.xor0.9.xby npm convention, so the current "latest of everything" combination is mutually incompatible. Downgrading tovarlock@0.7.4with@varlock/1password-plugin@0.3.5and@varlock/vite-integration@0.2.10works cleanly with no peer warnings.What is actually happening?
Observed behaviour
Two different crashes depending on environment, both rooted in the same failure:
Locally:
On Netlify (same schema, same package versions):
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
loadPluginModuleCJS/executePluginModuleso 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.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.