#defineConfig import.meta.dev

30 messages · Page 1 of 1 (latest)

quartz rivet
#

Hi Everybody!
I need to archive a (theoretically) easy thing.

In my defineConfig inside of app.config.ts, I need to resolve a variable based on if I'm running the server with bun run dev or with bun start.

The problem is that, I can't find the environment variable that tells if I'm running as DEV or as PROD.

In fact import.meta.env doesn't seem to be exporting a DEV or PROD variable.

Is there any way for archiving this?

Sharing the code down here

import { defineConfig } from "@solidjs/start/config";
import { resolve } from "path";
import { env } from "process";

export default defineConfig({
  vite: {
    ssr: {
      external: ["@prisma/client"],
    },
    resolve: {
      alias: {
        ".prisma/client/index-browser":
          "./node_modules/.prisma/client/index-browser.js",
        $fonts: resolve(
          /* import.meta.dev ? */ "/public/fonts" /* : "/fonts" */
        ),
      },
    },
    server: {
      port: parseInt(env.PORT || "3000"),
    },
  },
  server: { preset: env.PRESET || "node-server" },
  middleware: "./src/middleware.ts",
});
hazy pike
#

i believe the confusion is around the difference between application code (where all these non standard import meta stuff are configured to work) and setup code(where non of these makes sense because they're the one that set them up, most of the time this is the way it is)

process.env is the right path but at this point you have to get in and handle them yourself with dotenv or similar, node --env-file

the most important thing is the actual environment which is usually the shell you're executing the command, there are multiple ways to set them up
here's one for most POSIX shells
e.g NODE_ENV=foo PORT=bar command

#

(theoretically) easy
because tool builders have to make it seem like it's easy for the sake of DX but it's nearly impossible to cover everywhere

quartz rivet
#

Gm.
Thanks for your answer.

I actually didn't think about setting the ENV variable via CMD. And that's a great idea for archiving the desired result!

So, is this the only way for reaching my goal, in your opinion?

Thank you very much! :))

hazy pike
#

nah, .env also loads it lol

#

heck no, it only gets loaded on when the config gets saved

#

alright
here's another one

import { config } from "dotenv";
config();

bun run --env-file .env dev
quartz rivet
#

I had already set-up my env correctly.
console.logging(env) shown an interesting variable called npm_lifecycle_event that is start when npm start and dev when npm run dev.

I tried it out and it seems to work.
Do you think it's fine using this variable here rather than defining a custom one?

hazy pike
#

Probably not, it's likely added by npm run. You can also put the env in npm scripts.

#

for example
package.json

{
  "scripts": {
    "build": "NODE_ENV=production vinxi build"
  }
}
quartz rivet
#

Perfect. Thanks! :))

#

(Just checked, yarn bun and npm have the npm_lifecycle_event variable btw)

hazy pike
#

yarn bun etc probably emulate npm in terms of execution

quartz rivet
#

Ok, so, my final approach will be something like this:

import { defineConfig } from "@solidjs/start/config";
import { resolve } from "path";
import { env } from "process";

export default defineConfig({
  vite: {
    ssr: {
      external: ["@prisma/client"],
    },
    resolve: {
      alias: {
        ".prisma/client/index-browser":
          "./node_modules/.prisma/client/index-browser.js",
        $fonts: resolve(
          env.npm_lifecycle_event === "dev" ? "/fonts" : "/public/fonts"
        ),
      },
    },
    server: {
      port: parseInt(env.PORT || "3000"),
    },
  },
  server: { preset: env.PRESET || "node-server" },
  middleware: "./src/middleware.ts",
});

But, adding a custom env variable via CMD works perfectly fine either.

Thanks for the help ❤️

hazy pike
#

I wouldn't rely on it because

{
  "hello": "vinxi dev"
}
#

it'd be hello in this case

#

process.env.NODE_ENV should be working but for some reason, it's not. This is a bug.

#

Ok, it seems to be a timing issue.

#

make vite a function that returns the object instead

#

then you can use process.env.NODE_ENV

# 
import { defineConfig } from "@solidjs/start/config";

export default defineConfig({
  vite: () => {
    console.log(process.env.NODE_ENV !== "production");
    return {};
  },
});
quartz rivet
quartz rivet
hazy pike
#

Yeah, it's buggy at the moment but on build it shows up with the correct value production

#

but vite needs to be a function

#

vite seems to be working

#

feel free to file an issue

quartz rivet
quartz rivet
#

Posting down here my final configuration:

import { defineConfig } from "@solidjs/start/config";
import { resolve } from "path";
import { env } from "process";

export default defineConfig({
  vite: () => {
    return {
      ssr: {
        external: ["@prisma/client"],
      },
      resolve: {
        alias: {
          ".prisma/client/index-browser":
            "./node_modules/.prisma/client/index-browser.js",
          $fonts: resolve(
            env.NODE_ENV !== "production" ? "/fonts" : "/public/fonts"
          ),
        },
      },
      server: {
        port: parseInt(env.PORT || "3000"),
      },
    };
  },
  server: { preset: env.PRESET || "node-server" },
  middleware: "./src/middleware.ts",
});

Thank you very much @hazy pike :))