Hello i have a question regarding the ember-cli-build.
So i have ember apps that intended to load different assets (css,js,addons) based on parameter that i add in dotEnv or in config/environment.js. The aim is to make ember app able to load dynamic asset based from where the url is accesssed.
The Questions is. Does ember-cli-build can get configuration parameter or get another value from dotEnv file ?
ember-cli-build.js file is just a node script at the end of the day so you can use environment variables via
process.env.<varname> or you could use something like dotenv (you’d just have to install globally or locally and import it). Hope that answers your question!
I’d like to add that you can also access
config/environment.js so that you set properties at build time and access then at run time.
If it’s a fixed list of values, you may generate builds for all possible values once and then serve them depending on request origin.
If it’s not a fixed list, I would recommend to do one build and alter the run-time configuration when serving the file. The run-time configuration is included in
index.html as a
<meta> tag. It’s a URI encoded JSON.
Hello thanks for the response. Yes i figured generating build per request is not possible. However including all fixed list would load unnecesarry assets and affect the loadtime.
So in the end i use Ember Cli Head to able load dynamic assets in and use jquery to append the js file. Although i am not sure that was the cleanest way to do external js loading.
I did not meant that you should include all assets in one build. I tried to suggest that you could do multiple builds one for each origin. Something like:
BUILD_FOR_ORIGIN=foo.com ember build --prod --output-path=dist/foo.com
BUILD_FOR_ORIGIN=bar.com ember build --prod --output-path=dist/bar.com
ember build --prod --output-path=dist/default
Upload all builds to your webserver and configure it to serve the correct build depending on request.
This does only work if you know the list of build variants beforehand. And it has a huge impact on time needed to do a full deployment. But it’s far easier and does not have as much edge cases as manipulating the build output.
That approach has an impact on timing. The dynamic assets won’t be loaded until full application is booted. That might be okay for your use case but could cause issues. I just wanted to mention it for other people coming across this thread.