Description

IgorMinar

opened on Aug 9, 2017

Issue body actions

build optimizer currently contains a whitelist for all packages that should be processed:

devkit/packages/angular_devkit/build_optimizer/src/build-optimizer/build-optimizer.ts

Lines 21 to 33 in a6cc863

	/(\\|\/)node_modules(\\|\/)@angular(\\|\/)animations(\\|\/)/,
	/(\\|\/)node_modules(\\|\/)@angular(\\|\/)common(\\|\/)/,
	/(\\|\/)node_modules(\\|\/)@angular(\\|\/)compiler(\\|\/)/,
	/(\\|\/)node_modules(\\|\/)@angular(\\|\/)core(\\|\/)/,
	/(\\|\/)node_modules(\\|\/)@angular(\\|\/)forms(\\|\/)/,
	/(\\|\/)node_modules(\\|\/)@angular(\\|\/)http(\\|\/)/,
	/(\\|\/)node_modules(\\|\/)@angular(\\|\/)platform-browser-dynamic(\\|\/)/,
	/(\\|\/)node_modules(\\|\/)@angular(\\|\/)platform-browser(\\|\/)/,
	/(\\|\/)node_modules(\\|\/)@angular(\\|\/)platform-webworker-dynamic(\\|\/)/,
	/(\\|\/)node_modules(\\|\/)@angular(\\|\/)platform-webworker(\\|\/)/,
	/(\\|\/)node_modules(\\|\/)@angular(\\|\/)router(\\|\/)/,
	/(\\|\/)node_modules(\\|\/)@angular(\\|\/)upgrade(\\|\/)/,
	/(\\|\/)node_modules(\\|\/)@angular(\\|\/)material(\\|\/)/,

This whitelist is for prefixing function calls with pure annotation for uglify.

Webpack is working on introducing pure module feature that npm packages opt-in to via "pure-module": true in package.json.

Since the meaning of this flag is the same as what we need for purification of top level function calls, we could get rid of the whitelist and use the same package.json metadata as webpack.

Since all of the modules in the whitelist will also want to benefit from the pure-modules feature in webpack, sharing the flag would allow us to get rid of the whitelist.

Activity

1. filipesilva commented on Aug 10, 2017

   

   filipesilva

   on Aug 10, 2017

   Contributor

   More actions

   For reference: https://github.com/webpack/webpack/tree/feature/pure-module/examples/pure-module

   Doing this on the build-optimizer itself raises some problems. Build optimizer doesn't know about modules, and it actually doesn't know about file systems either. It only knows about file contents and (if given) file paths.

   And this is relevant in a webpack context because the file contents for a given file path may or may not be related to that path on disk. For instance, the file may have been through some loaders already and it's current content changed, or the given file path may not even exist at all (this happens for AOT code).

   The one that truly is aware of the pure-module flag is the system that is resolving the module - webpack in this case, maybe others in the future. So my suggestion is that we pass that information along in the build-optimizer call in the consumer:

   const boOutput = buildOptimizer({ content: input, pure: true });
   

   This way the module loader can tell build optimizer that it thinks this given module is pure, and build optimizer itself drops the whitelist and doesn't even bother checking the file path, which was a problematic way to detect these anyway.

   Reacted by Joe Liccini
2. IgorMinar commented on Aug 22, 2017

   

   IgorMinar

   on Aug 22, 2017 via email

   ContributorAuthor

   More actions

   If I remember correctly from looking at the pure-module branch diff, webpack does keep track of which modules are pure and should be able to pass that information along to all the plugins and loaders.

   …

   On Thu, Aug 10, 2017 at 1:59 AM Filipe Silva ***@***.***> wrote: For reference: https://github.com/webpack/webpack/tree/feature/pure-module/examples/pure-module Doing this on the build-optimizer itself raises some problems. Build optimizer doesn't know about modules, and it actually doesn't know about file systems either. It only knows about file contents and (if given) file paths. And this is relevant in a webpack context because the file contents for a given file path may or may not be related to that path on disk. For instance, the file may have been through some loaders already and it's current content changed, or the given file path may not even exist at all (this happens for AOT code). The one that truly is aware of the pure-module flag is the system that is resolving the module - webpack in this case, maybe others in the future. So my suggestion is that we pass that information along in the build-optimizer call in the consumer: const boOutput = buildOptimizer({ content: input, pure: true }); This way the module loader can tell build optimizer that it thinks this given module is pure, and build optimizer itself drops the whitelist and doesn't even bother checking the file path, which was a problematic way to detect these anyway. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#89 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANM6GFX1-l7YnWy9knSfXi1GlB4Xl_Nks5sWsZVgaJpZM4Oyw9d> .
3. filipesilva

   self-assigned this

   on Oct 16, 2017
4. filipesilva

   added

   comp: angular-devkit/build-optimizer

   type: feature

   on Oct 16, 2017
5. alexeagle commented on Sep 4, 2018

   

   alexeagle

   on Sep 4, 2018

   Contributor

   More actions

   This issue was moved to angular/angular-cli#12103
6. alexeagle

   closed this as completedon Sep 4, 2018

Issue actions