Different base url based on "modes" for build

[velvet tundra]

Normally, the build process is rather straightforward for me and I dont need anything other the defaults for my config. However, the I now need to change my baseUrl based on the mode I am building for and to be honest, I am a bit lost. I have seen the docs where it describes the default environment variables for dev and prod, but I actually need to declare one for "staging". What is the best way to go about handling this?

For example, my three modes are:

1. Dev => localhost (nothing changed)
2. Staging => a server that we normally just ftp into and put static assets at like placeholder-site.com/staging/current-site-name
3. Production => a different server than "staging" that we ftp into the root and upload the site files at like current-site-name.com

I have looked around and have found wildly different solutions, but I was wondering what the "correct" way of handling this would be based on vite/astro.

[velvet tundra]

Different base url based on "modes" for build

I guess I should have clarified a bit more. I am really only wanting to change the base url based on different modes: dev/staging/production since I host my projects in various folders on my staging environment.

ie:
staging => /staging/current-project-name
production => /. (hosted on server root)

[fallow jay]

Another one like me who likes over-engineering solutions!

Not sure about what you prefer, but I just tried to set a environment variable with CLI/.env and it just... works!

You can override MODE.

I literally set MODE to foobar in a dummy .env and console.log(import.meta.env.MODE); returns foobar server-side.

[wind cliff]

Typically you have multiple configs, but an env var is also good ( and easy )

[fallow jay]

Maybe you should wait the POV of a maintainer to be sure that overriding this environment variable is not breaking something on Astro-side. I can assert that it is just a variable set by the framework and never used by itself. Not enough knowledge.

GitHub search is a bit... boring. Can't do case sensitive search... Would need to clone the repo...

[velvet tundra]

Yeah, I just wanted to make life a bit easier since this was in a git repo and I hate having a modified file every time I am building for staging, production, etc etc..

I attempted to create 2 .env files
.env.staging => BASE_URL=/staging/test
.env.production => BASE_URL=/staging/test

And in my astro.config:

export default {
 base: process.env.BASE_URL
}

However, when I build using pnpm build --mode staging I am not seeing the base prepended to the assets. I am most likely doing something wrong here. I dont use env variables that much around

[fallow jay]

You can't use the CLI solution?

Maybe the answer would to check on Vite config too

[wind cliff]

I don't think the env is loaded before the config is read

you can read it in before config though

use env var directly ( not .env file ) is probably what you want here, so it can be used in ci easier

You can even wire that up in gh actions to use it for branch staging, prod, etc

[fallow jay]

I want to try something

I think Vite is smart enough to load only .env.foobar

[velvet tundra]

Sorry for my noobiness on all of this. I really havent used .env a lot at work save for a few small projects using nextjs with planetscale

[fallow jay]

No worries, webdev is opinionated and complicated

[velvet tundra]

How did you go about doing it via the cli?

[fallow jay]

I am looking for something cleaner

I am currently reading Vite file configuration

We can set Vite settings directly with Astro

And currently, it is Vite that is handling MODE

Meh...

Not working?

Adding

vite: {
  mode: 'staging',
}

in astro.config.mjs is not working.

But it should? https://vitejs.dev/config/shared-options.html#mode

And then Vite would load .env.staging, normally

Might be worth to open a discussion on Github

I don't know if astro build --mode staging is working and that astro dev--mode staging just not work

[velvet tundra]

Yeah, I had found this issue earlier and it was marked as completed. So I guess I am going to have to dig a bit further. I appreciate you taking the time to look into it!

[fallow jay]

I pushed a message to the #frameworks

You can only wait now! :-)