Skip to content

Multiple environment.ts are confusing #933

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

Closed
johnpapa opened this issue May 26, 2016 · 15 comments
Closed

Multiple environment.ts are confusing #933

johnpapa opened this issue May 26, 2016 · 15 comments

Comments

@johnpapa
Copy link
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
Copy link

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
Copy link

sgbeal commented Jun 2, 2016

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

@serhiisol
Copy link
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
Copy link

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
Copy link
Contributor

@sgbeal Ok, got it

@francisoud
Copy link

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

@antonybudianto
Copy link
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
Copy link

randyaa commented Sep 9, 2016

I believe this is resolved with the webpack version of CLI

@filipesilva
Copy link
Contributor

@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
Copy link

@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
Copy link
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
Copy link

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

@ratbeard
Copy link

Link to docs is https://github.com/angular/angular-cli/blob/9d29cbca0f0c04bb5998cc2cd15180456656ad7e/docs/documentation/build.md

@Sweetog
Copy link

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

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests