Running scripts that have access to Kit stores (like $env)

[acarl005]

Describe the problem

I really like the $env store, so I migrated the whole fullstack app to access env vars only through $env. The problem now is that I have some backend node.js scripts (database setup and migrations and such) which need to import some model code from my app. The model code imports $env, and so I can't import those into my script because that prevents me from running my script, b/c when I try to run my script with node my-script.js I get an error like this

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '$env'

...because a dep of my dep is $env. I need my script to be run via SvelteKit somehow in order to resolve the $env alias.

Describe the proposed solution

Something like this would be nice...

svelte-kit run my-script.js

That would allow devs to run scripts which can access the $env store.

Alternatives considered

The only alternative I can think of would be to go back to using vanilla process.env. This has the disadvantage of needing to manually load via something like dotenv, as well as losing the protections of private vs public env vars, and losing the ability to statically build env values into the bundle.

Importance

nice to have

Additional Information

No response

[bluwy]

I feel like this is out of scope of SvelteKit. $env is a SvelteKit specific feature only, and for external node scripts, those should be handled by nodejs only. Plus, if it's for database setup and migrations etc, public/private protections shouldn't matter since you're always running in a private environment.

[acarl005]

if it's for database setup and migrations

I just want to clarify something here. I have code which isn't only for my scripts which accesses $env. It's shared between my SvelteKit app and my scripts. It's the model logic, or the "M" part of an MVC app. Basically, if I want to share any of my app code with my scripts, it cannot use $env. If I remove $env from those parts, now my app has 2 different ways of accessing the environment vars, which is not ideal b/c we lose consistency.

public/private protections shouldn't matter since you're always running in a private environment

To continue on my previous explanation, since its the shared model logic that is actually accessing $env, it is in "danger" of accidentally importing a private env var into client code, as someone on the team might add something like a data validation into one of these model classes that they think should be used on the client side too.

Having said that, I do acknowledge that it skirts the boundary of what is "in scope" of SvelteKit. This nonetheless may still be out of scope. This $env feature is just such a good idea that I wish it could be used outside of the SvelteKit context, so thumbs up to the team for conceiving such a good idea that I find myself desiring it in this manner!

As a follow-up suggestion, maybe this feature is more appropriate for a 3rd party library to implement? Is that even possible? I don't know much about the Kit codebase yet, but if the team thinks that's feasible to build, I'd be happy to give it a try and put it out there for the community.

[bluwy]

@dominikg has been implementing a separate vite plugin that achieves similarly to what SvelteKit has. The problem is that the plugin creates virtual files, instead of writing to the disk like SvelteKit does now, though that will change soon too.

Since ESM loaders are still experimental, you can use something like vite-node to execute the file specifically that's also powered by Vite plugins.

The small issue now is that there's also two ways of importing envs again (albeit similar). But come to think of it, running just vite-node without the plugin might work too as SvelteKit's env handling should be compatible with vite-node.

[tcc-sejohnson]

IMO, this is outside the scope of Kit, though I can see the frustration. My recommendation would be to use something like proxyquire to stub the $env modules when you need to.

[acarl005]

@bluwy Awesome suggestion! It turns out that straight up npx vite-node my-script.js works out of the box. Now I can use $env everywhere 🙌

[DoisKoh]

I've run into a similar issue - this time with Vitest. I'm trying to run tests on a script that imports env vars using SvelteKit's $env.

I really want to use $env but I've had to switch back to import.meta.env... to circumvent this.