search

vuestorefront / vue-storefront-1

The open-source frontend for any eCommerce. Built with a PWA and headless approach, using a modern JS stack. We have custom integrations with Magento, commercetools, Shopware and Shopify and total coverage is just a matter of time. The API approach also allows you to merge VSF with any third-party tool like CMS, payment gateways or analytics. Newest updates: https://blog.vuestorefront.io. Always Open Source, MIT license.
https://www.vuestorefront.io
MIT License
19 stars 13 forks source link

Configuration mismatches when building once for many environments #328

Open michael-bouvy opened 4 years ago

michael-bouvy commented 4 years ago

Current behavior

When building in production mode, using yarn build the client-side configuration is generated based on default.json, local.json and production.json (taken from NODE_ENV), and written in both dist/app.*.js and dist/core-service-worker.js.

This is an issue as a single build may be (re)usable on several environments (ie. staging, preprod, prod), leveraging the NODE_CONFIG_ENV environment variable, ie:

NODE_CONFIG_ENV=staging yarn start

It actually works fine for server-side calls, as node-config loads the config at runtime upon current configured environment.

Expected behavior

Configurable values (ie. URLs) should not be hardcoded at build time in generated code (dist/ directory), so that a single application build can be usable (in a Docker image for instance) on several stages/envs.

Steps to reproduce the issue

:arrow_down:

Can you handle fixing this bug by yourself?

Which Release Cycle state this refers to? Info for developer.

Pick one option.

Environment details

pkarw commented 4 years ago

Hi there! There is a config option: dynamicConfigReload which is set by default to false. Try just switching it to true - it will cause the config reload by each SSR request which apparently should solve this issue

michael-bouvy commented 4 years ago

Thanks @pkarw!

I actually had this option in mind, but didn't think it could help. Will give it a try.

michael-bouvy commented 4 years ago

Gave this a try, but I don't get expected result: GraphQL API endpoint used is still production one (as NODE_ENV=production), despite having set NODE_CONFIG_ENV=my-env (with config/my-env.json existing with env-specific conf).

Here is my default.json conf:

{
  "server": {
    "dynamicConfigReload": true,
    "dynamicConfigContinueOnError": false,
    "dynamicConfigExclude": ["entities", "localForage", "shipping", "boost", "query"],
    "dynamicConfigInclude": []
    },
    ...
}
michael-bouvy commented 4 years ago

I guess this issue should be reopened, @pkarw ? 🙂

pkarw commented 4 years ago

Sure, reopening

pkarw commented 4 years ago

Please check if this won’t solve the isssue: https://github.com/lorenwest/node-config/wiki/Environment-Variables#custom-environment-variables

We’re using this solution in storefront cloud to pass the variables via env to prebuilt docker containers

michael-bouvy commented 4 years ago

This is an interesting feature, but does not fit the need: environment variables are only processed on server side, and from what I can see, once the JS is bundled at build time with a given environment-specific config, values are not reloaded, even with dynamicConfigReload

pkarw commented 4 years ago

I’m changing this issue to feature request; the config file is bei ng compiled into app bundle it’s our basic feature from the very beginning; so the suggested solution is to build the app once per ENV because it also involves some code level optimizations, different webpack config, including/excluding source maps. Pretty complex one.