Env Leak (Vite, Vike, Vike-Solid, Bun) about vike HOT 9 CLOSED

Makes sense. Although I'd export each variable individually so that Rollup can do its tree-shaking.

from vike.

It does show a warning in development though, right? I'm thinking Vike should throw an error also in dev instead of merely showing a warning.

from vike.

Ah, I see why I made it to only be a warning back then:

Only a warning for faster development DX (e.g. when user toggles ssr: boolean or onBeforeRenderIsomorph: boolean)

from vike.

I'll go ahead and close this, but let me know if you don't see any warning in which case it would be a bug.

Thanks for opening this bug report!

from vike.

Ah yeah, yup. There's a warning. Didn't catch that. Thanks! So long as it fails me to do this at some point (builds), that's good enough.

Thanks as well!

from vike.

Just to add to this. I'm now realizing that config.ts for all my environment variables is kinda bad.

I just wanted a single interface to access and document and give defaults for my environment variables. But I guess I can't do that here.

A better thing I did is to create two separate config files:

• config.private.ts
• config.public.ts

// config.private.ts

/** Only place private configurations here. */
export const privateConfig = {
  /** Port of the app (in dev). */
  PORT: (import.meta.env.PORT || 3000) as number,
  /** Development or Production. */
  NODE_ENV: (import.meta.env.NODE_ENV ?? "development") as
    | "development"
    | "production",
  /** DB-specific settings. */
  database: {
    /** The url of the database. */
    URL: import.meta.env.DATABASE_URL!,
    /** Not needed in development. https://docs.turso.tech/local-development#sqlite */
    AUTH_TOKEN: import.meta.env.DATABASE_AUTH_TOKEN!,
  },
  /** S3Bucket-specific settings. */
  s3: {
    /** Application Key ID in B2 (accessKeyId in S3) */
    ACCESS_KEY_ID: import.meta.env.S3_ACCESS_KEY_ID!,
    /** Application Key in B2 (secretAccessKey in S3) */
    SECRET_ACCESS_KEY: import.meta.env.S3_SECRET_ACCESS_KEY!,
    /** Name of the bucket. */
    BUCKET_NAME: import.meta.env.S3_BUCKET_NAME! ?? "spend-snap",
    /** Region of the bucket. */
    REGION: import.meta.env.S3_REGION! ?? "us-east-1",
    /** URL of the bucket. */
    ENDPOINT: import.meta.env.S3_ENDPOINT! ?? "http://localhost:4566",
  },
};

// config.public.ts

/** Only place public configurations here. */
export const publicConfig = {
  BASE_ORIGIN:
    import.meta.env.PUBLIC_ENV__BASE_ORIGIN || "http://localhost:3000",
};

Hope this helps out anyone who needs ideas on structure!

from vike.

Curious: why not only using .env files? See https://vike.dev/env.

from vike.

Curious: why not only using .env files?

Honestly, just DX and easier maintenance for me. I got this practice from my work. Not sure if it's bad practice though.

The benefits for me are:

• I can add readable TSDocs to each env variable (Like where I can get them from, what they're used for, etc.).
• Typesafety, just of mind, but not fool-proof.
• Default Values.
• Source of truth (Easily find "actual" references of the env variable in the code by "Find All References" instead of doing Fuzzy Search Buffers for the whole codebase)
• Refactoring (I can rename them easily using the LSP - F2 on VSCode).

That's about it.

from vike.

Ahh right2! That is true. Thanks for this!

from vike.