New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Environment-specific configurations via polymer.json #408

Open
cdata opened this Issue Sep 16, 2016 · 10 comments

Comments

Projects
None yet
10 participants
@cdata
Member

cdata commented Sep 16, 2016

As a Polymer app author,
when I build my sharded application with polymer-cli,
I want to include a specialized environment configuration in the build output,
so that my app can adapt to being deployed to production.

Environment-specific Configurations

This is a design proposal for a new feature of the polymer build command.

Users can include an "environment" field in polymer.json that is a mapping of environment names to configurations. polymer build --env $envName can be used to select one of the configurations. Selecting a configuration causes that configuration to set as Polymer's configuration in the build artifact. So, if I have a polymer.json like:

{
  "entrypoint": "index.html",
  "shell": "src/foo-app/foo-app.html",
  "fragments": [
    "src/foo-app/fragment-one.html",
    "src/foo-app/fragment-two.html",
    "src/foo-app/fragment-three.html"
  ],
  "environment": {
    "production": {
      "lazyRegister": true,
      "custom": "foo"
    }
  }
}

And I run the CLI with polymer build --env production, I get a script tag added to my index that looks like:

<script>
window.Polymer = {
  lazyRegister: true,
  custom: "foo"
};
</script>

Alternative approach: configure global ENV property

One alternative approach would be to configure a global ENV property with the configuration values. This has the advantage of being more generalized, at the cost of requiring additional coordination in the main document. Assuming the above polymer.json is used, the polymer build --env production command would produce this script in the document:

<script>
<!-- NOTE: ENV name is just a strawman -->
window.ENV = window.ENV || {};
window.ENV.lazyRegister = true;
window.ENV.custom = 'foo';
</script>

Using this alternative approach, the same end result as the first design could be achieved with the following basic cooperation by the app author:

<script>
if (window.ENV) {
  window.Polymer = window.ENV;
}
</script>

Rationale

There is some precedence for this feature in other similar CLI tools:

@pdesjardins90

This comment has been minimized.

Show comment
Hide comment
@pdesjardins90

pdesjardins90 Apr 7, 2017

Any update on this?

pdesjardins90 commented Apr 7, 2017

Any update on this?

@JonathanSidego

This comment has been minimized.

Show comment
Hide comment
@JonathanSidego

JonathanSidego Apr 10, 2017

How are people handling environmental variables in Polymer at the moment?

JonathanSidego commented Apr 10, 2017

How are people handling environmental variables in Polymer at the moment?

@pdesjardins90

This comment has been minimized.

Show comment
Hide comment
@pdesjardins90

pdesjardins90 Apr 10, 2017

Having 3 config files (local, staging, prod), I've resolved to overwrite my config file at build time on my CI server with something like this :

if [ "$BRANCH_NAME" = "staging" ]; then mv app.conf.staging.json app.conf.json; fi

it gets the job done for CI, but a CLI argument would be much better

pdesjardins90 commented Apr 10, 2017

Having 3 config files (local, staging, prod), I've resolved to overwrite my config file at build time on my CI server with something like this :

if [ "$BRANCH_NAME" = "staging" ]; then mv app.conf.staging.json app.conf.json; fi

it gets the job done for CI, but a CLI argument would be much better

@bradrydzewski

This comment has been minimized.

Show comment
Hide comment
@bradrydzewski

bradrydzewski Jun 18, 2017

I have two minor requests to consider...

First, would you consider adding these environment-specific configurations to the polymer serve command as well? With our react frontend (now being re-written in polymer) we are able to define certain configuration parameters at runtime which is useful for our contributors:

npm start -- --scheme <drone scheme> \
             --host   <drone host> \
             --token  <drone api token>

which might look something like this:

npm start -- --scheme http \
             --host   localhost:8080 \
             --token  eyJhbGciOiJIUzI1NiIsInR5cCI....

Your project can consume variables declared in your environment as if they were declared locally in your JS files. By default you will have NODE_ENV defined for you, and any other environment variables starting with REACT_APP_.

Second, would you also consider the ability to define and/or override parameters using environment variables similar to how this is handled by react [1]. This could look something like the following:

POLYMER_APP_custom=foo polymer build --env production

or alternatively with command line parameters:

polymer build --env production --env-var custom=bar

[1] https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md#adding-custom-environment-variables

bradrydzewski commented Jun 18, 2017

I have two minor requests to consider...

First, would you consider adding these environment-specific configurations to the polymer serve command as well? With our react frontend (now being re-written in polymer) we are able to define certain configuration parameters at runtime which is useful for our contributors:

npm start -- --scheme <drone scheme> \
             --host   <drone host> \
             --token  <drone api token>

which might look something like this:

npm start -- --scheme http \
             --host   localhost:8080 \
             --token  eyJhbGciOiJIUzI1NiIsInR5cCI....

Your project can consume variables declared in your environment as if they were declared locally in your JS files. By default you will have NODE_ENV defined for you, and any other environment variables starting with REACT_APP_.

Second, would you also consider the ability to define and/or override parameters using environment variables similar to how this is handled by react [1]. This could look something like the following:

POLYMER_APP_custom=foo polymer build --env production

or alternatively with command line parameters:

polymer build --env production --env-var custom=bar

[1] https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md#adding-custom-environment-variables

@byjg

This comment has been minimized.

Show comment
Hide comment
@byjg

byjg Jul 10, 2017

This proposal is awesome.

byjg commented Jul 10, 2017

This proposal is awesome.

@MeTaNoV

This comment has been minimized.

Show comment
Hide comment
@MeTaNoV

MeTaNoV Sep 14, 2017

It would be definitely be something very useful that most of us are already implementing one way or another...

MeTaNoV commented Sep 14, 2017

It would be definitely be something very useful that most of us are already implementing one way or another...

@bendavis78

This comment has been minimized.

Show comment
Hide comment
@bendavis78

bendavis78 Oct 1, 2017

I'd love to see this implemented. Has anyone started a branch for this? I think it makes the most sense to put these in something window.ENV, and then any environment-specific global polymer options can be set in the document itself.

bendavis78 commented Oct 1, 2017

I'd love to see this implemented. Has anyone started a branch for this? I think it makes the most sense to put these in something window.ENV, and then any environment-specific global polymer options can be set in the document itself.

@jab

This comment has been minimized.

Show comment
Hide comment
@jab

jab Oct 11, 2017

Contributor

Would it make sense for this to allow specifying some shared configuration that all environments would inherit, which they could extend with any additional fields needed / selectively override any fields they need to override?

Contributor

jab commented Oct 11, 2017

Would it make sense for this to allow specifying some shared configuration that all environments would inherit, which they could extend with any additional fields needed / selectively override any fields they need to override?

@c256985

This comment has been minimized.

Show comment
Hide comment
@c256985

c256985 Nov 16, 2017

So, if I understand this correctly, we'd need a change to the Polymer CLI to be able to pass in an ENV mode (dev, prod, whatever), and a change to the Polymer framework itself to read the appropriate subtree of the configuration. Would the user put the configuration in polymer.json, or somewhere else? We'd also want the code to be flexible enough to accommodate any ENV mode label.

c256985 commented Nov 16, 2017

So, if I understand this correctly, we'd need a change to the Polymer CLI to be able to pass in an ENV mode (dev, prod, whatever), and a change to the Polymer framework itself to read the appropriate subtree of the configuration. Would the user put the configuration in polymer.json, or somewhere else? We'd also want the code to be flexible enough to accommodate any ENV mode label.

@mtnourji

This comment has been minimized.

Show comment
Hide comment
@mtnourji

mtnourji Aug 15, 2018

2 years later, there is still no implementation about this ?

mtnourji commented Aug 15, 2018

2 years later, there is still no implementation about this ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment