https://kotlinlang.org logo
Join Slack
Powered by
How do I export the static layout of the file in d...
# kobweb
f
How do I export the static layout of the file in dev env to a different folder this does not work in 
conf.yaml
Copy code
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"
I am attempting to deploy and I need variant's of the site export
d
There's no concept of doing an export in dev mode
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.
What value were you hoping for running an exported site in dev mode?
(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)
f
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.
d
Ah I haven't thought about different variants yet
If you can share a concrete example of what exactly you want to do, I can think about it
f
What I intended to do with the snippet I provided above is to export eh dev variant using
Copy code
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
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.
c
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
✅ 1
d
If you want preprod, that's already supported by firebase! I do it all the time with my Kobweb sites.
But variants, like exporting Android flavors, is not officially supported at the moment. I need to think about it more.
f
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.
No pressure/urgency at all I'll figure a way around it.
d
You can specify app globals in your build script
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
I'll add readme docs for app globals today
f
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
🤞 1
d
Let me know if this works for you or if you run into any trouble.
👍 1
f
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.
d
Just set an env variable on the CLI and then call kobweb export
f
Oooh, that'll work ?
I didn't know about that
d
I forget the exact syntax, but if you're using bash, something like 
$ SOME_ENV_VAR=value kobweb export
maybe?
✅ 1
f
Okay I think I get, I think I'll set the Environment variable on the run configuration use to export.
d
Yeah, give that a shot
f
Then that should be available within the code right? Or would I need to pass it to the globals
d
You should be able to read it from your gradle build script
And then pass it into app globals yeah
f
Alright, great. That sounds good
Thank you
d
BTW, 
kobweb export --help
should show you some parameters called 
--gradle...
That lets you pass values directly into gradle which might be another approach here if the env variable is annoying
👍 1
for example, I think you could do 
kobweb export --gradle -Pkey=value
or something like that
Totally forgot about that feature for a bit
f
Trying ...
Open in Slack
PreviousNext
Powered by