How do I export the static layout of the file in dev env to a different folder this does not work in...

# kobweb

[Funyinoluwa Kashimawo]

How do I export the static layout of the file in dev env to a different folder
this does not work in conf.yaml

server:
  files:
    dev:
      contentRoot: "build/processedResources/js/main/public"
      script: "build/dist/js/developmentExecutable/admin.js"
      siteRoot: ".kobweb/site-dev"
      api: "build/libs/admin.jar"
    prod:
      script: "build/dist/js/productionExecutable/admin.js"
      siteRoot: ".kobweb/site"

[Funyinoluwa Kashimawo]

I am attempting to deploy and I need variant's of the site export

[David Herman]

There's no concept of doing an export in dev mode

[David Herman]

You either run in dev mode (where files are read out of your build/ folder), or you export your site and run it in prod mode.

[David Herman]

What value were you hoping for running an exported site in dev mode?

[David Herman]

(Exporting your site is really mainly there for support for static hosting services and also SEO, which you don't need to worry about at dev time)

[Funyinoluwa Kashimawo]

Oooh I think I might have gotten the approach wrong. So I am deploying to firebase hosting and I wanted to have a different variant of my site deployed so I have on dev and one prod.

I planned on setting up a run config to export the file then deploy for each variant because firebase needs a path to the exported site content.

[David Herman]

Ah I haven't thought about different variants yet

[David Herman]

If you can share a concrete example of what exactly you want to do, I can think about it

[Funyinoluwa Kashimawo]

What I intended to do with the snippet I provided above is to export eh dev variant using

kobweb export --env dev --layout static

but the export command does not accept the env option.


The use case is for cli's that require a public path to build the site.

The ideal case would be that.
• User wants to build a variant
• User exports the site for a particular variant to a particular path
• the build environment is observable within the code

[Funyinoluwa Kashimawo]

But then again I don't think you should do this with the prod and dev in conf.yaml because some people might require multiple variants and I don't think that was you plan for that.

I guess what you did is similar to debug and release

And what I am looking for is more like android flavors.

[CLOVIS]

I think it would be less confusing if you called what you're asking "staging" or "preprod" :
• dev : local development
• preprod : deployed environment that is only visible to testers
• prod : deployed environment visible to real users

[David Herman]

If you want preprod, that's already supported by firebase! I do it all the time with my Kobweb sites.

[David Herman]

https://firebase.google.com/docs/hosting/test-preview-deploy#preview-channels

[David Herman]

But variants, like exporting Android flavors, is not officially supported at the moment. I need to think about it more.

[Funyinoluwa Kashimawo]

Alright, Thanks @David Herman.

The preview option did not work for me because the app build from that has know way to know internally which environment it was built in.

[Funyinoluwa Kashimawo]

No pressure/urgency at all I'll figure a way around it.

[David Herman]

You can specify app globals in your build script

[David Herman]

So maybe set an environment variable, have your build script read it and see an app global, then set the env variable before export #1, upload that, then change the env variable before export #2 and repeat. However export #2 will overwrite export #1

[David Herman]

I'll add readme docs for app globals today

[Funyinoluwa Kashimawo]

Thank you very much, that will actually work.
• Have the script build in an env, export, upload.
• Then build the default env again and export to restore the state

[David Herman]

https://github.com/varabyte/kobweb/tree/0.15.3#setting-application-globals

In case that helps!

[David Herman]

Let me know if this works for you or if you run into any trouble.

[Funyinoluwa Kashimawo]

I've looked at the docs but it won't work for my case. I need to pass a property to the kobweb export command and be able to access the property within the code.

[David Herman]

Just set an env variable on the CLI and then call kobweb export

[Funyinoluwa Kashimawo]

Oooh, that'll work ?

[Funyinoluwa Kashimawo]

I didn't know about that

[David Herman]

I forget the exact syntax, but if you're using bash, something like $ SOME_ENV_VAR=value kobweb export maybe?

[Funyinoluwa Kashimawo]

Okay I think I get, I think I'll set the Environment variable on the run configuration use to export.

[David Herman]

Yeah, give that a shot

[Funyinoluwa Kashimawo]

Then that should be available within the code right? Or would I need to pass it to the globals

[David Herman]

You should be able to read it from your gradle build script

[David Herman]

And then pass it into app globals yeah

[Funyinoluwa Kashimawo]

Alright, great. That sounds good

[Funyinoluwa Kashimawo]

Thank you

[David Herman]

BTW, kobweb export --help should show you some parameters called --gradle...

[David Herman]

That lets you pass values directly into gradle which might be another approach here if the env variable is annoying

[David Herman]

for example, I think you could do kobweb export --gradle -Pkey=value or something like that

[David Herman]

Totally forgot about that feature for a bit

[Funyinoluwa Kashimawo]

Trying ...