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

Multiple environment.ts are confusing #933

Closed
johnpapa opened this Issue May 26, 2016 · 14 comments

Comments

Projects
None yet
@johnpapa
Contributor

johnpapa commented May 26, 2016

The current model for environment variables is to have 3 places for files:

  1. /src/environment.ts
    This is here so when we type in VS Code or our favorite editor we get intellisense. it is not used for a build
  2. /config/environment.dev.ts and /config/environment.prod.ts
    This is where we put our env settings for the different environments. It is copied to the dist/ folder.
  3. /dist/environment.js
    This is the one that gets run, we do not edit this one.

Follow this scenario ... we need an env variable to point to a web url for our APIs. So we create a

export const environment {
  url: '/api/foo`
};

and we put it in /src/environment.ts. We then import it with import { environment } from './environment. VS Code is happy (as is any tsc compiler command).

Now we run ng serve and browse to the app, and we see an error in the console about how it doesnt know what url is. Oops, we didnt put this in the config/environment.dev.ts (nor prod) files. OK, so we go do that and now we can run and serve smoothly.

Now ... we add a new env for showDebugMessages: true. We set it to true for dev and false for prod. We recall that we need to do this in the /config/environment.*.ts files so we feel we are good. But we forgot we also need to put the same setting in the /src/environment.ts. It is not used ... but we need something there. Do we out false or true for this new setting? It doesn't matter because we are not using it.

export const environment {
  url: '/api/foo`,
  showDebugMessages: true
};

My point here is that it can be confusing on how to do this and not make a mistake.

Are there any thoughts on how to prescribe this? Or how to make it easier? Have you considered an interface?

My Env:

$ ng -v
angular-cli: 1.0.0-beta.5
node: 4.2.3
os: darwin x64

cc @spboyer

@spboyer

This comment has been minimized.

Show comment
Hide comment
@spboyer

spboyer May 27, 2016

Posted on how to use and the drawbacks here: https://tattoocoder.com/angular-cli-using-the-environment-option/

interface, at least in the current folder structure is not a good workflow. The interface would either need to be at the base root of the project or in a place where referencing it doesn't make sense.

spboyer commented May 27, 2016

Posted on how to use and the drawbacks here: https://tattoocoder.com/angular-cli-using-the-environment-option/

interface, at least in the current folder structure is not a good workflow. The interface would either need to be at the base root of the project or in a place where referencing it doesn't make sense.

@sgbeal

This comment has been minimized.

Show comment
Hide comment
@sgbeal

sgbeal Jun 2, 2016

fwiw, we get by just fine without environment.ts. We only have/use the dev/prod copies.

sgbeal commented Jun 2, 2016

fwiw, we get by just fine without environment.ts. We only have/use the dev/prod copies.

@serhiisol

This comment has been minimized.

Show comment
Hide comment
@serhiisol

serhiisol Jun 6, 2016

Contributor

Also it would be great if we could make parent configuration, which config/environment.*.ts might extend, for instance:

_config/environment.base.ts_

export var environment = {
    API_BASE_URL: "http://example.com/api"
}

_config/environment.dev.ts_

import {extend} from 'lodash';
import {base} from './environment.base';

export var environment = extend(base, {
    dev: true
});

currently EmberCli base project reads and compiles only specific file based on version (prod or dev)

_angular-cli/lib/broccoli/environment.js_

  // Load the content of the environment file.
  const filePath = path.join(project.root, `config/environment.${env}.ts`);
  const source = fs.readFileSync(filePath, 'utf-8');
  const result = ts.transpile(source, {
    target: ts.ScriptTarget.ES5,
    module: ts.ModuleKind.CommonJs
  });

So what I'm saying is that you can't import something and extend it later

Contributor

serhiisol commented Jun 6, 2016

Also it would be great if we could make parent configuration, which config/environment.*.ts might extend, for instance:

_config/environment.base.ts_

export var environment = {
    API_BASE_URL: "http://example.com/api"
}

_config/environment.dev.ts_

import {extend} from 'lodash';
import {base} from './environment.base';

export var environment = extend(base, {
    dev: true
});

currently EmberCli base project reads and compiles only specific file based on version (prod or dev)

_angular-cli/lib/broccoli/environment.js_

  // Load the content of the environment file.
  const filePath = path.join(project.root, `config/environment.${env}.ts`);
  const source = fs.readFileSync(filePath, 'utf-8');
  const result = ts.transpile(source, {
    target: ts.ScriptTarget.ES5,
    module: ts.ModuleKind.CommonJs
  });

So what I'm saying is that you can't import something and extend it later

@sgbeal

This comment has been minimized.

Show comment
Hide comment
@sgbeal

sgbeal Jun 6, 2016

@SergeySolonko this doesn't require special angular-cli support, i believe. Simply put environment.base.ts in your project's top-level src tree (not in config), and your extend() example "should" (i believe) work as-is. Except that... in 1.0.0-beta.5 environment.xxx.ts cannot reference ANY external symbols (e.g. window) and cannot import project-level includes (see ticket #833). Once that ticket is resolved, your feature request should come "for free."

sgbeal commented Jun 6, 2016

@SergeySolonko this doesn't require special angular-cli support, i believe. Simply put environment.base.ts in your project's top-level src tree (not in config), and your extend() example "should" (i believe) work as-is. Except that... in 1.0.0-beta.5 environment.xxx.ts cannot reference ANY external symbols (e.g. window) and cannot import project-level includes (see ticket #833). Once that ticket is resolved, your feature request should come "for free."

@serhiisol

This comment has been minimized.

Show comment
Hide comment
@serhiisol

serhiisol Jun 6, 2016

Contributor

@sgbeal Ok, got it

Contributor

serhiisol commented Jun 6, 2016

@sgbeal Ok, got it

@francisoud

This comment has been minimized.

Show comment
Hide comment
@francisoud

francisoud Jul 22, 2016

Hi guys,
Do you know why I can't get it to work with my unit tests ? #1419

francisoud commented Jul 22, 2016

Hi guys,
Do you know why I can't get it to work with my unit tests ? #1419

@antonybudianto

This comment has been minimized.

Show comment
Hide comment
@antonybudianto

antonybudianto Aug 18, 2016

Contributor
  • Having env's interface is nice to have so that new developer able to know what're needed for each environment
  • Even better if the file is gitignored and conform to https://12factor.net/config so that it's scalable
// from 12factor
such as the development, test, and production environments in Rails. 
This method does not scale cleanly: as more deploys of the app are created, 
new environment names are necessary, such as staging or qa.
As the project grows further, developers may add their own special environments 
like joes-staging, resulting in a combinatorial explosion of config which makes managing deploys of the app very brittle

just my 2 cent

P.S: I've created env addon https://github.com/antonybudianto/angular-cli-env, for those interested. it's dotenv inspired

Contributor

antonybudianto commented Aug 18, 2016

  • Having env's interface is nice to have so that new developer able to know what're needed for each environment
  • Even better if the file is gitignored and conform to https://12factor.net/config so that it's scalable
// from 12factor
such as the development, test, and production environments in Rails. 
This method does not scale cleanly: as more deploys of the app are created, 
new environment names are necessary, such as staging or qa.
As the project grows further, developers may add their own special environments 
like joes-staging, resulting in a combinatorial explosion of config which makes managing deploys of the app very brittle

just my 2 cent

P.S: I've created env addon https://github.com/antonybudianto/angular-cli-env, for those interested. it's dotenv inspired

@randyaa

This comment has been minimized.

Show comment
Hide comment
@randyaa

randyaa Sep 9, 2016

I believe this is resolved with the webpack version of CLI

randyaa commented Sep 9, 2016

I believe this is resolved with the webpack version of CLI

@filipesilva

This comment has been minimized.

Show comment
Hide comment
@filipesilva

filipesilva Oct 10, 2016

Member

@randyaa I agree. Originally the functionality was more confusing and less documented than it is now.

Documentation can be found https://github.com/angular/angular-cli#build-targets-and-environment-files, and now the third file is not needed.

Member

filipesilva commented Oct 10, 2016

@randyaa I agree. Originally the functionality was more confusing and less documented than it is now.

Documentation can be found https://github.com/angular/angular-cli#build-targets-and-environment-files, and now the third file is not needed.

@matodrobec

This comment has been minimized.

Show comment
Hide comment
@matodrobec

matodrobec Nov 16, 2016

@filipesilva
I would like to import environment to the app.components.ts like
import { environment } from './environment';
therefore I have to create src/app/environment.ts. Why the value of environment.production is still false when I run ng serve --environment=prod ? I am using angular-cli: 1.0.0-beta.19-3

matodrobec commented Nov 16, 2016

@filipesilva
I would like to import environment to the app.components.ts like
import { environment } from './environment';
therefore I have to create src/app/environment.ts. Why the value of environment.production is still false when I run ng serve --environment=prod ? I am using angular-cli: 1.0.0-beta.19-3

@serhiisol

This comment has been minimized.

Show comment
Hide comment
@serhiisol

serhiisol Nov 16, 2016

Contributor

@matodrobec Hi, you can create workaround for your case, just simply add index.ts file in environments folder with content:

export { environment } from './environment';

and then you can easily import environment through index.ts like so

In app.component.ts

import {environment} from '../environments';

You have to use '../' because environments folder is in the folder one level up

Contributor

serhiisol commented Nov 16, 2016

@matodrobec Hi, you can create workaround for your case, just simply add index.ts file in environments folder with content:

export { environment } from './environment';

and then you can easily import environment through index.ts like so

In app.component.ts

import {environment} from '../environments';

You have to use '../' because environments folder is in the folder one level up

@praveen-nuovo

This comment has been minimized.

Show comment
Hide comment
@praveen-nuovo

praveen-nuovo Feb 2, 2017

I followed the above process, But I got this error --> src/app/app.component.ts (17,22): Cannot find namespace 'environment'

praveen-nuovo commented Feb 2, 2017

I followed the above process, But I got this error --> src/app/app.component.ts (17,22): Cannot find namespace 'environment'

@Sweetog

This comment has been minimized.

Show comment
Hide comment
@Sweetog

Sweetog Feb 24, 2017

I am really surprised how hard it is to find a simple tutorial/solution for cmd webpack -p --env.prd true and an environment configuration being available in an Angular2 Typescript app, I developed a very simple solution https://github.com/Sweetog/yet-another-angular2-boilerplate

Sweetog commented Feb 24, 2017

I am really surprised how hard it is to find a simple tutorial/solution for cmd webpack -p --env.prd true and an environment configuration being available in an Angular2 Typescript app, I developed a very simple solution https://github.com/Sweetog/yet-another-angular2-boilerplate

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