this is not ideal.... ideally we should share the functionality 😓

we could do that by exposing some API from wrangler but that would feel a bit gnarly to me (since this seems like internal logic more than anything else to me)

in my opinion, one of the biggest strengths in having a monorepo setup would be to share code... so I would really consider having some internal package for shared logic such as this, in that way code could be shared very easily without needing to expose it publicly in any of our packages

anyways that's quite overkill for something as simple as this, but anyways I wanted to mention it just because I think setting up something like that can in general be very useful as this need to share code does come up from time to time (from my point of view, we pay the price of setting the thing up just once but then it pays off every time there's such a need).

This is really picky so feel free to ignore but my preference would be to call this.emitFile here and for the function to just return the content rather than also writing the file. Makes it easier to see what's happening.

With your suggestion is sounds like you'd want to always save the .dev.vars file even if there is no content to save? That'd be ok, but I think it'd be nicer and clearer if we saved the file only when actually needed (keep in mind that this.emitFile also logs the information to the user)

So I've applied a similar change: 3bb0dd1

Let me know what you think 🙂

(I've also added a comment to clarify why we're saving such a file, although I understand that it is a bit unnecessary)

I prefer not to have the . so that it is clearer that this this is a manually inputted string (otherwise without seeing the implementation someone could thing that this was generated by something like my ${devVarsFileName} variable A)

if you find it confusing I can change the strings to something like MY_DEV_VAR_A = "my .dev.vars variable A for the staging environment (or something like that)

Note, mostly unrelated to this PR:

The vite-plugin catalog pins @types/node but that will not work as expected because of

		"overrides": {
			// ...      
			"@types/node": "$@types/node"
		},

So there would need to be a more specific override there for the plugin package

is there any benefit in having a variable here (i.e. do we expect to add more files)
Otherwise it looks looks inlining would be less convoluted

the benefit of the variable are:

• it is nicer to have if we can indeed add more files in the future
• if is a self documenting variable, the variable name helps (at least to me) understanding that it does

those are not huge benefits I don't mind inlining the array if that's what you strongly prefer

rant:

Seeing this annoys me, same thing as with function(path, config, true, true, false, "")

	const { CLOUDFLARE_ENV: cloudflareEnv } = vite.loadEnv(
		viteEnv.mode,
		root,
		/* what is this??? usually the name of the parameter */""
	);

maybe I should start reviewing PR in VSCode instead....

I agree, this could be cleared if we owned the API and used a config object instead

with Vite's API we can still make this clearer by having a temporary documenting variable, but that might not be what you personally want since before you said that you find such a variable "convoluted"