Add new --bindings command line argument

[petebacondarwin]

This argument is a JSON stringified array of all the bindings that are being passed from Wrangler in the same format as would be uploaded to a Worker during publishing...

For example, if you have the following vars in wrangler.toml:

[[vars]]
a = "10"
b = 20
c = { value: 30 }

Then we actually create bindings that look like:

[
 { "type": "plain_text", "name": "a", "text": "10" },
 { "type": "json", "name": "b", "json": "20" },
 { "type": "json", "name": "c", "json": "{ \"value\": 30 }" }
]

The same would apply to other binding types such as

• kv_namespace
• wasm_module
• text_blob
• durable_object_namespace
• r2_bucket

It is then up to Miniflare to parse the JSON and work out how to assign the bindings to the appropriate plugins.
This would mean that Wrangler would not need to use the specific keys such as --kv, --binding, etc in a backwardly compatible way.

[petebacondarwin]

@JacobMGEvans is keen to be involved in the implementation of this

[mrbbot]

Hey everyone! 👋 Just had a chat with @JacobMGEvans and proposed an alternative. Instead of adding a --bindings CLI argument to Miniflare, I think Wrangler should be calling Miniflare via its API.

Basically instead of using require.resolve("miniflare/cli") here...
https://github.com/cloudflare/wrangler2/blob/43417469ef071e4f673507ff1dfa11f3bde29428/packages/wrangler/src/dev.tsx#L298
...Wrangler would call its own separate script file that looked something like Miniflare's cli.ts:

miniflare/packages/miniflare/src/cli.ts

Lines 93 to 104 in 870b401

	const mf = new Miniflare(mfOptions);
	try {
	// Start Miniflare development server
	await mf.startServer();
	await mf.startScheduler();
	} catch (e: any) {
	mf.log.error(e);
	process.exitCode = 1;
	// Unmount any mounted workers
	await mf.dispose();
	return;
	}

It would be up to you to define the options format then, and you could use a stringified JSON array if you wanted. The API is much more amenable to Wrangler's use case anyways and it already supports arbitrary bindings:

// See https://miniflare.dev/get-started/api#reference for reference
const options = {};

const bindings = JSON.parse(process.argv[2]);
for (const binding of bindings) {
  if (binding.type === "plain_text") {
    options.bindings ??= {};
    options.bindings[binding.name] = binding.text;
  }
  // ...
}

// Also already supports JSON bindings
options.bindings["b"] = 42;

const mf = new Miniflare(options);

cc @threepointone

[threepointone]

I have a branch where instead of passing everything as command line args, I generate a wrangler.toml instead. @mrbbot do json bindings work via wrangler.toml in miniflare?

[petebacondarwin]

Yeah that sounds like a much better idea. I was actually wondering if there was potential for a programmatic approach.

[petebacondarwin]

I have a branch where instead of passing everything as command line args, I generate a wrangler.toml instead. @mrbbot do json bindings work via wrangler.toml in miniflare?

I think a direct programmatic approach is cleanest, right? Rather than having another layer of indirection.

[mrbbot]

do json bindings work via wrangler.toml in miniflare?

No, they're intentionally stringified to match Wrangler 1 behaviour:

miniflare/packages/core/src/plugins/bindings.ts

Lines 116 to 127 in 870b401

	@Option({
	type: OptionType.OBJECT,
	logName: "Wrangler Variables",
	fromWrangler: ({ vars }) => {
	if (!vars) return;
	// Wrangler stringifies all environment variables
	return Object.fromEntries(
	Object.entries(vars).map(([key, value]) => [key, String(value)])
	);
	},
	})
	[kWranglerBindings]?: Record<string, any>;

[threepointone]

think a direct programmatic approach is cleanest, right? Rather than having another layer of indirection.

Just trying to avoid a major refactor at this point, but if that's the only option we have, sure I guess.