Skip to content

Latest commit

 

History

History
12 lines (7 loc) · 2.61 KB

angular-1x-has-no-dependencies-and-therefore-its-OK-to-include-it-with-Webpacks-option-noParse-So-wrong.md

File metadata and controls

12 lines (7 loc) · 2.61 KB

Angular 1.x has no dependencies and therefore it's OK to include it with Webpack's option noParse. So wrong.

Angular 1.x has no dependencies and therefore it's OK to include it with Webpack's option noParse. This idea I have learnt in the great online screencast (Russian) devoted to Webpack. The option noParse instructs Webpack not to analyze the source code of the included program and not to inject any dependencies to it. This can boost the performance when dealing with big libraries which have no dependencies and export global variables to communicate with other parts of the system. And indeed, Angular is huge, it works without any dependencies and exports global variable.

So I optimized my Webpack process with not parsing Angular and later lost 1.5 working days trying to understand why my system did not work. I had included two other modules jstree, which is a jQuery plugin and the Angular wrapper over jstree, ng-js-tree. Of course, JQuery was also involved and things just exploded:

The thing is, Angular HAS dependency! It is tricky, though. This dependency is JQuery, but if you don't provide jQuery it will use it's internal lighter version of JQuery named JQLite and will silently continue working. Here is the Angular's source code proving that.

So here is what happened under Webpack's control: 1) JQuery was initialized; 2) jstree was initialized and attached to the JQuery; 3) Angular was initialized, but since it was checking for window.jQuery and it was undefined, Angular was initialized with its internal beast JQLite. window.jQuery was undefined because Webpack does not allow globals, it manages global variables like jQuery on its own and passes them to modules which mention those variables in their source code. But that source code must be parsed first, and I had noParse for Angular :-). 4) ng-js-tree was initialized but with the DOM element wrapped by JQLite, not by real JQuery to which jstree was attached. 5) the miserable crash happened when ng-js-tree tried to access DOM element, provided to it, assuming that was JQuery DOM element while it was JQLite DOM element.

Hence, be careful when you optimize your Webpack with a noParse option for some module. Even if that module works just fine without any dependencies, there might be some complex interdependencies which will make you cry like in my case it was with Angular, JQuery, jstree, and ng-sj-tree.