Accessing env variables in standalone scripts

[petdomaa100]

Describe the problem

Unless I'm missing something, there is currently no way to access $env/static/private outside of the Vite context, the file simply doesn't exist.

My database driver is defined in a file that's imported by SvelteKit code and a DB migration script. The latter is executed as a standalone CLI script using bun.

In the standalone execution context import.meta.env is defined but $env/static/private doesn't exist, and in the SvelteKit execution context it's the opposite. Is there a recommended way to deal with this?

My current solution:

const SOME_ENV_VAR = import.meta.env.SOME_ENV_VAR ?? (await import('$env/static/private')).SOME_ENV_VAR;

Seems quite hacky and relies on top-level await but it works fine for my usecase.

Describe the proposed solution

Ideally, there would be a command in the svelte-kit CLI that runs a file in the Vite context.

Alternatives considered

No response

Importance

nice to have

Additional Information

No response

[einarpersson]

I have experienced the same problem. I have a /scripts folder which contains various useful maintanence / admin standalone ts-scripts which I occasionally run (locally). Since node now have type-stripping it is very nice to be able to run these typescript scripts. They can in turn import and reuse functions (like db calls) from the app. However, then you cannot use sveltekit things like $env/... as far as I know. This has led me to abandon these constructs completely and instead just using process.env (loosing some optimization I guess).

For me this feels like a wider problem perhaps. Svelte has always been very aligned with standards etc, but with $env/ and $app/server scattered around the code base, the business logic easily gets tied to sveltekit (which is not only a future concern, but as describe here also makes it harder to just run a script and reuse a function from the app). I guess going forward with remote functions I'll have to create two separate files, one for db calls and one wrapper (*.remote.ts).

I don't know if this is solvable, just wanted to share my dev user experience.