Provide the ability to remove code needed only in dev mode from the production bundle

[markostanimirovic]

Which @angular/* package(s) are relevant/related to the feature request?

core

Description

Several NgRx libraries have features/checks that are only used in development mode (e.g. store runtime checks, component store lifecycle hooks check, store devtools, etc).

Proposed solution

Expose the ngDevMode/isNgDevMode variable to the public API, so it can be used in Angular libraries that have dev mode-related functionalities, but also in user codebases if needed.

This feature could significantly reduce the size of production bundles in many Angular codebases.

Alternatives considered

Currently, we can use ngDevMode to remove dev mode-related logic from the production bundle in the following way:

declare const ngDevMode: boolean;
const isNgDevMode = typeof ngDevMode === 'undefined' || !!ngDevMode;

// ...

if (isNgDevMode) {
  console.warn('@ngrx/store: ...');
}

However, this global variable is not part of the public API and it can be risky to rely on it.

[JeanMeche]

Hi Marko, we already have isDevMode, have you tried it ?

[markostanimirovic]

Yes, we're using the isDevMode function, but we would like to eliminate "dead" code from the production bundle which is possible with ngDevMode.

[JeanMeche]

Well isDevMode is ngDevMode under the hood.

angular/packages/core/src/util/is_dev_mode.ts

Lines 20 to 22 in d6efd71

	export function isDevMode(): boolean {
	return typeof ngDevMode === 'undefined' || !!ngDevMode;
	}

And terser should be able to strip the code that is behind if (isDevMode()) {}

[arturovt]

Terser is not able to tree-shake the code if the function, returning a statically analyzeble value, is used in more than 1 module. Terser is not analyzing the entire project's dependency graph, that's why ngDevMode is defined everywhere in the Angular code (and not isDevMode()), which means it doesn't perform cross-module tree-shaking. You can check the following example:

// file-1.js
import { isDevMode } from './shared';

isDevMode() && console.log('file-1');

// file-2.js
import { isDevMode } from './shared';

isDevMode() && console.log('file-2');

// shared.js
export function isDevMode() {
  return !!ngDevMode;
}

// webpack.config.js
const TerserPlugin = require('terser-webpack-plugin');

module.exports = {
  entry: ['./src/file-1.js', './src/file-2.js'],
  optimization: {
    minimize: true,
    minimizer: [
      new TerserPlugin({
        terserOptions: {
          compress: {
            global_defs: {
              ngDevMode: false,
            },
          },
        },
      }),
    ],
  },
};

The output code:

(() => {
  'use strict';
  var e = {
      768: (e, r, o) => {
        function t() {
          return !1;
        }
        o.d(r, { X: () => t });
      },
    },
    r = {};
  function o(t) {
    var n = r[t];
    if (void 0 !== n) return n.exports;
    var i = (r[t] = { exports: {} });
    return e[t](i, i.exports, o), i.exports;
  }
  (o.d = (e, r) => {
    for (var t in r)
      o.o(r, t) &&
        !o.o(e, t) &&
        Object.defineProperty(e, t, { enumerable: !0, get: r[t] });
  }),
    (o.o = (e, r) => Object.prototype.hasOwnProperty.call(e, r)),
    (0, o(768).X)() && console.log('file-1'),
    (0, o(768).X)() && console.log('file-2');
})();

If we update the entry property to include only ./src/file-1.js, the output code becomes the following:

(()=>{"use strict"})();

[markwhitfeld]

So, to understand this correctly, in order to achieve what is needed, would angular need to:

1. export the ngDevMode as a variable,
2. or add it to the global typescript namespace (in the angular lib)

to make this available to libs to be useful for tree shaking?

[JeanMeche]

1. export the ngDevMode as a variable,

ngDevMode is not a conventional constant. It's set the by the cli and declared as global inside the framework.

angular/packages/core/src/util/ng_dev_mode.ts

Lines 11 to 26 in 3a59de6

	declare global {
	/**
	* Values of ngDevMode
	* Depending on the current state of the application, ngDevMode may have one of several values.
	*
	* For convenience, the “truthy” value which enables dev mode is also an object which contains
	* Angular’s performance counters. This is not necessary, but cuts down on boilerplate for the
	* perf counters.
	*
	* ngDevMode may also be set to false. This can happen in one of a few ways:
	* - The user explicitly sets `window.ngDevMode = false` somewhere in their app.
	* - The user calls `enableProdMode()`.
	* - The URL contains a `ngDevMode=false` text.
	* Finally, ngDevMode may not have been defined at all.
	*/
	const ngDevMode: null|NgDevModePerfCounters;

[angular-robot]

This feature request is now candidate for our backlog! In the next phase, the community has 60 days to upvote. If the request receives more than 20 upvotes, we'll move it to our consideration list.

You can find more details about the feature request process in our documentation.

[maxime1992]

I've been using a little trick in my case with ngrx which is to have 2 files in which I define what I want, for example the redux dev tool import. In dev mode I import it, while in the other file I don't. I then use the angular cli swapping file capability to use the dev one at serve time and the prod one (with nothing it in except an empty array) at build time.

And because I feel like I'm absolutely not clear (end of day sorry 🙃) here's what I've got:

ngrx.ts:

import { ModuleWithProviders } from '@angular/core';
import { StoreDevtoolsModule } from '@ngrx/store-devtools';

// this file will be replaced by the prod version at build time!
// this is to make sure that we don't include `store-devtools` in our prod bundle
// https://ngrx.io/guide/store-devtools/recipes/exclude

export const ngrxModules: ModuleWithProviders<any>[] = [StoreDevtoolsModule.instrument({ maxAge: 25 })];

ngrx.prod.ts:

import { ModuleWithProviders } from '@angular/core';

export const ngrxModules: ModuleWithProviders<any>[] = [];

And in my Angular CLI config file:

          "fileReplacements": [
            {
              "replace": "apps/my-app/src/app/build-specifics/ngrx.ts",
              "with": "apps/my-app/src/app/build-specifics/ngrx.prod.ts"
            }
          ],

Now, while there's a work around for this... I have to admit that this feature would be a really nice to have. It's quite convoluted and error prone to swap files at build time. Meanwhile, in case anyone needs a workaround to make sure you don't bundle the entire code for the redux dev tool or others, you know where to look :)

[simeyla]

Edit: I've deleted most of my answer due to making an incorrect assumption about optimized constants. Unfortunately it looks like terser isn't smart enough to optimize constants imported from environment.ts (related to the use of webpack require).

---

I wouldn't ever want to use ngDevMode in application code - but for libraries perhaps it makes more sense.

[JeanMeche]

@simeyla The usecase forngDevMode is definitely oriented toward libraries that want to provide a similar behaviour as Angular :

Explicit logs and errors in devMode & only critical errors in prodMode (and less verbose).