Unable to perform Vitest integrations tests using $env/dynamic/private

[kyllerss]

Describe the bug

I finally got around to migrating away from import.meta.env.* for all of my environment variables and onto the SvelteKit-recommended $end/dynamic|static/public|private. I had a number of integration tests I had written in vitest that are now breaking with the following error:

FAIL  tests/integration/hooks.test.ts [ tests/integration/hooks.test.ts ]
Error: Cannot import $env/dynamic/private into client-side code
 ❯ Context.load node_modules/@sveltejs/kit/src/exports/vite/index.js:304:12
 ❯ Object.load node_modules/vite/dist/node/chunks/dep-67e7f8ab.js:40201:46
 ❯ loadAndTransform node_modules/vite/dist/node/chunks/dep-67e7f8ab.js:36553:24

My integration tests import a number of back-end modules (eg. database access code, etc...).

I am surprised by the fact that the integration tests are being treated as client code that is tripping up the server-client serialization safety mechanism.

I am at a loss as to what to do here. Any recommendations on how to address this issue? Is there any way I can turn off this safety mechanism for my integration tests? Is there something entirely different I should be doing to do database integration tests?

PS. My reproduction project is using the stock configuration that comes from a new project. It calls the vitest tests unit tests. I am not sure if I should be reading too much into that. If vitest is not the right place for writing these types of tests, what alternatives should I look into?

Reproduction

The reproduction test illustrates the problem when importing a class that makes a reference to $env/dynamic/private.

https://github.com/kyllerss/sveltekit-issue-8180

Logs

No response

System Info

System:
    OS: Linux 5.15 KDE neon 5.26 5.26
    CPU: (16) x64 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
    Memory: 9.68 GB / 15.34 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash
  Binaries:
    Node: 16.18.0 - ~/apps/node-v16.18.0-linux-x64/bin/node
    npm: 8.19.2 - ~/apps/node-v16.18.0-linux-x64/bin/npm
  Browsers:
    Brave Browser: 108.1.46.144
    Chrome: 108.0.5359.124
    Firefox: 108.0
  npmPackages:
    @sveltejs/adapter-auto: ^1.0.0 => 1.0.0 
    @sveltejs/kit: ^1.0.0 => 1.0.0 
    svelte: ^3.54.0 => 3.55.0 
    vite: ^4.0.0 => 4.0.1

Severity

serious, but I can work around it

Additional Information

No response

[dummdidumm]

Mhhhm, anything that ends with .server.js/ts is treated as "this code is safe". I guess we need to make the detection algorithm more sophisticated to also work with test files.

[benmccann]

Can you describe a realworld usecase for this? The example repository has a env-dynamic-private.test.ts test which directly imports environment variables, but that doesn't seem too realistic to me. If you have a +server.js file then I'd expect your test to be named something like server.test.js, which should work. Obviously that's not what you're doing, but it's not clear to me what the actual usecase is here

[kyllerss]

Ah, I can see my test example was confusing. I have updated the issue reproduction to be a little closer to what I am trying to do.

The use-case is using server-side code ($lib/server) directly in the tests for the purposes of seeding the test database and verifying db results. Code that accesses the database connection string (among other server-side properties) is not accessible/importable.

I tried changing the tests to follow the naming conversions you mentioned, but that didn't work either.

If there are naming conventions I should be using instead or something else I should be doing, I'd be happy to adopt them.

[benmccann]

Hmm, yeah, I see your test is also in $lib/server, so I would expect that to work: https://github.com/kyllerss/sveltekit-issue-8180/blob/main/src/lib/server/db_service.test.ts

@tcc-sejohnson any ideas about this one?

[elliott-with-the-longest-name-on-github]

Setting an alarm to take a look at this tonight.

[DoisKoh]

For me, my unit test files (ending in .spec.ts) sit next to the actual files they are testing (e.g. in $lib/stores); when I import env from $env/dynamic/private, it's detected as usage in client-side code.

[benmccann]

@DoisKoh are you importing $env/dynamic/private in your test or in your actual code? Can you share the file names of your code and corresponding test?

[DoisKoh]

I'm importing it in my tests (not actual code).

File names/paths:
Actual Code: src\lib\components\stores\Clients.ts
Test Code File: src\lib\components\stores\Clients.spec.ts