feat(@schematics/angular): remove environment files in new applications

[alan-agius4]

This commit removes the usage of environment files and fileReplacements in new application projects. Previously, the environment files was used to distinguish between a prod build to invoke enableProdMode. The enableProdMode however needed only for the case of JIT mode in production mode, which is a rare case as JIT mode is recommanded to be used in production.

In the CLI, calling enableProdMode is not needed as ngDevMode/isDevMode is set using the minifier. See: angular/angular#47475

This change only affects newly applications generated by ng new/ ng generate application. Environments are not being removed, deprecated, or discouraged.

[alan-agius4]

blocked on angular/angular#47475

[eneajaho]

Hi,
Environment files are used a lot in the user-land code and that's what helps us while developing features in order to distinguish dev or production server urls for example.
I understand that the file-replacements feature won't be removed, but it would make the discoverability of the feature worse.
Having it ready when using ng new is really good.

Maybe better documentation and schematics to generate this stuff would be a great replacement?

[e-oz]

Please don't do this. Some of us are using fileReplacements for other things (related to i18n), and having 2 separate configs is very convenient.

[sourav-bhar]

Echoing above sentiments, please don't do this, ie. fix what's not broken. A lot of developers (including myself) depend on this critical feature. Taking it away for no good end-user facing reason would be a shame and a big red flag for me.

[Den-dp]

I can only see these environment files and corresponding fileReplacements removed if there will be a generator that can scaffold this feature on-demand

[crutchcorn]

Truthfully, I'll be the dissenting voice to many of the "Don't do this" comments here. While I'm in favor of not removing these features full-stop, I think the less code we can have in ng new is better for newcomers and those looking to cross-shop Angular from other frameworks.

Regularly, I find those that are learning frameworks like Angular asking "What do these configuration options mean?" and getting lost in a lot of the noise. I think this will go a long way in helping build trust with those that are learning for the first time, or even those of us that don't regularly configure environment files.

[SanderElias]

@alan-agius4 I assume this PR is about taking out this feature from newly generated projects?
That is no problem, and I encourage such a change.

Disabling this option for existing projects will be a big breaking change. And there are still good uses for those things to exist.

[e-oz]

@SanderElias if something is discouraged from use - it will be deprecated and then removed. Usually it works this way :)

[DmitryEfimenko]

As others have mentioned, removing environment files is a terrible idea since this a great feature and this PR will hurt its discoverability. How about something else instead:

At my work we've started a new pattern. The default prod/dev configurations are very vague when it comes to the meaning they convey. I see a lot of projects associate bundle optimization configurations and the environment configurations under the same flag - dev or prod. prod is especially troublesome since it can mean many things. prod environment? prod optimization settings? These are two very different settings and we found it useful to split them up. So now we have the following configs:

• optimizations-on
• optimizations-off
• env-dev
• env-beta
• env-prod

The optimizations-[on/off] configurations deal with bundle optimizations. These configs usually don't deal with environment files.
The env-[dev/beta/prod ] configurations deal with setting baseHref, api URLs, API keys and so on. These configs usually have some environment replacements.

This way we have a few scripts we use, but we can also easily run commands mixing and matching these configuration settings:

{
  "start": "ng serve -c env-dev,optimizations-off",
  "build-beta": "ng build -c=env-beta,optimizations-on",
  // ... etc
}

That's the change I'd rather see in new application out of the box. Heck, I guess it could have been a separate feature request...

[khalilou88]

I am with removing it because it's not the only solution to provide env variables and I always thought that Angular force us to use this approach... Personally, I prefer to inject a json file for prod/staging env and I hard coded the variables for dev env if no json provided. Like this I can use the same version for my app in many environments without rebuilding it to add a new env.

[alan-agius4]

Thank you all for the feedback.

The fileReplacements functionality is not being removed and if it was, it will firstly follow a deprecation cycle and an alternate solution will be provided.

There are 2 parts to this change, both of which are for new applications.

1. Remove enableProdMode call. This is mainly a noop as when invoked of it sets ngDevMode to false which is already done when running the build using the optimization option/flag.
2. Remove the now redundant environment files in newly generated projects. This is part of a greater effect to reduce the files and boilerplate that the CLI generates to reduce the "noise" for new users.

Users wishing to use the fileReplacements feature are still able to do so.

[HyperLife1119]

I think when creating a project the cli could ask the user if they want an environment file, just like the cli asks which css preprocessor I want.
This can take good care of both old and new users.

[dgp1130]

@alan-agius4 already added some details, but just to elaborate a little more:

To be very clear to those skimming the PR environment files are not being removed, deprecated, or discouraged. They solve very real problems for users and we have no plans to drop that particular feature.

What this PR does is remove some unnecessary boilerplate in ng new apps. Historically we generated environment files by default solely for the purpose of setting enableProdMode(), however we can update the framework to not require this call, so we can drop environments in the ng new app. Users are still free to add environments if and when it is useful to do.

The goal here is to reduce the complexity of the generated ng new app and reduce the cognitive burden for new developers learning Angular and its toolchain. Environments are an advanced feature which isn't critical to learn for new developers. Later in their Angular learning journey they can discover and use environments to solve specific problems they encounter.

We do recognize that not generating environments by default does impact discoverability and usability. This is something we think can be improved in documentation and tutorials, as well as some improved schematics. We feel these are solvable problems without impacting a new developer's experience getting started with Angular.

Hopefully that clarifies our intent and can alleviate some concerns in the community. As we get closer to v15 we'll have more conversations within the community about this approach. Folks watching PRs are just getting an early glimpse into things we haven't figured out all our communications for just yet. So look forward to more discussion and insight in the future.

[angular-automatic-lock-bot]

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.}