[angular/core] make DebugServices treeshakable (~10KB savings)

[alexeagle]

From @aitboudad on October 28, 2017 10:20

Bug Report or Feature Request (mark with an x)

- [ ] bug report -> please search issues before submitting
- [x] feature request

Area

- [x] devkit
- [ ] schematics

Desired functionality

Uglify is not able to remove unused debug services bocause of condition: core.js#L13946 and replacing that condition with createProdServices() resulted in ~10KB savings

-- var /** @type {?} */ services = isDevMode() ? createDebugServices() : createProdServices();
++ var /** @type {?} */ services = createProdServices();

Copied from original issue: angular/devkit#244

[alexeagle]

From @filipesilva on October 28, 2017 10:47

/cc @IgorMinar

[alexeagle]

From @IgorMinar on October 28, 2017 17:51

This is very interesting but the implementation relies on a side effect of
the pure top level functions optimization. It could also be considered as a
breaking change in some scenarios. I'll look into this more deeply next
week.

On Sat, Oct 28, 2017, 12:47 PM Filipe Silva notifications@github.com
wrote:

/cc @IgorMinar https://github.com/igorminar

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
angular/devkit#244 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AANM6PviSjDX7GkCyoEfzJr1Qm6GLsWeks5swwYqgaJpZM4QJ5Lb
.

[alexeagle]

From @IgorMinar on October 31, 2017 13:37

I've been thinking about this and it should be safe to build this optimization into build optimizer. @filipesilva what do you think?

[alexeagle]

From @trotyl on November 2, 2017 2:28

It would also save about 2.4KB in Closure Compiler when hard-coded isDevMode to return false.

Then comes an awkward situation, before we don't need to combine Closure Compiler with Build Optimizer since Closure Compiler could handle all cases Build Optimizer did. But that is not true any more.

[alexeagle]

From @filipesilva on November 4, 2017 10:2

The options to fix this on Build Optimizer are suboptimal I feel... because it compounds the CLI "environments" feature with the Angular enableProdMode feature. Let me explain this better.

In a default CLI app setup, doing --prod uses --environment=prod that has a (runtime) flag. That flag will, in default projects, activate enableProdMode in main.ts. So indeed the CLI could tell build optimizer that it was called with --prod, and build optimizer could strip out the debug services.

But what if the user uses other environment files? Or what if the user changes logic in main.ts? The enableProdMode call happens at runtime. Static analysis would be required at build time to determine whether the debug services should really be removed.

I think that #12200 would enable a fix for this issue as well, as it makes devMode a compile time concept instead of a runtime one.

[alexeagle]

From @IgorMinar on November 4, 2017 15:28

Yeah, you are right about this. I tagged that issue as v6 candidate.

On Sat, Nov 4, 2017 at 11:02 AM Filipe Silva notifications@github.com
wrote:

The options to fix this on Build Optimizer are suboptimal I feel...
because it compounds the CLI "environments" feature with the Angular
enableProdMode feature. Let me explain this better.

In a default CLI app setup, doing --prod uses --environment=prod that has
a (runtime) flag. That flag will, in default projects, activate
enableProdMode in main.ts. So indeed the CLI could tell build optimizer
that it was called with --prod, and build optimizer could strip out the
debug services.

But what if the user uses other environment files? Or what if the user
changes logic in main.ts? The enableProdMode call happens at runtime.
Static analysis would be required at build time to determine whether the
debug services should really be removed.

I think that #12200
#12200 would enable a fix for
this issue as well, as it makes devMode a compile time concept instead of a
runtime one.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
angular/devkit#244 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AANM6CRsbn3zs1a17IqhgMUGa-Nnt0glks5szDYpgaJpZM4QJ5Lb
.

[alan-agius4]

I had a look at this and changing isDevMode() with ngDevMode will reduce an ng-new application size by 0.23Kb.

Is there any reason why we use isDevMode instead of ngDevMode? //cc @IgorMinar.

Transferring to the FW repo, since this is more of an @angular/core issue.

[jelbourn]

@IgorMinar this is supposed to be resolved by the combination of Ivy and ngDevMode, right?

[JoostK]

Closing as obsolete, since these services are ViewEngine specific.

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