Examples & Documentation about angular-webpack-plugin HOT 6 CLOSED

I am sorry I haven't written more about it. I did intend to, but I was never fully satisfied with the results.

The best I can offer at the moment is the angular-seed fork I did as an example: https://github.com/stackfull/angular-seed

I still try to answer an issues as best I can, but I'm not currently using the plugin in production.

from angular-webpack-plugin.

I've looked at the fork a bit but the complexity of a MEAN.JS application makes things a little less straight forward. I'm basically looking for the ability to do the following:

Split vendor libraries (all of which are bower_components) into their own bundle; while keeping the Angular application itself contained in a second bundle. If you could spend just a minute or two looking at the structure of MEAN.JS (specifically, the public directory), you might be able to suggest a good starting point for me. Hopefully I'm not asking too much of you :)

Thanks in advance!

from angular-webpack-plugin.

At first glance (I'm afraid I've never looked at mean.js before) it doesn't look compatible with the angular-webpack-plugin. There are 2 main reasons:

1. The plugin is parsing files looking for angular.module(). If this is hidden via the ApplicationConfiguration.registerModule global, it won't be able to parse it.
2. The modules are constructed procedurally which is kind of upside down for something like webpack to deal with.

This last point is the killer and it's really common in angular apps which is why this plugin will never really work properly. webpack (and any tool that combines dependencies) needs to know which files depend on which other files at compile time. The plugin helps webpack understand what modules are defined and required by each angular file. A common pattern in angular is to define the module in one file and then add controllers/services to that module in another. The problem is that there is then nothing to declare the dependency from the point of view of a tool looking for the module.

For example, if an application module "app" has a dependency on the module "foo", webpack must locate "foo" in a file. It can only do this by mapping names to paths. Once "foo.js" has been found, it is parsed for dependencies recursively. In the common angular pattern outlined above, webpack is stuck at this point. Angular modules only work at runtime, another step is required to organise the files (such as recursively adding script tags to the html).

The only way to structure angular apps to work with this plugin is to have a module defined in every file. For example, "foo.js" would contain something like angular.module('foo", ["foo.controllers", "foo.services"]);. Looking at mean.js, that doesn't look feasible. I think you'll always need some kind of scripted step to concat the files by glob.

from angular-webpack-plugin.

Actually, it would be possible to write a new plugin for webpack that scans all the files up front and pre-aliases the module names, but you're kind of bypassing webpack at that point.

from angular-webpack-plugin.

Well that saves me a ton of headache trying to bend the plugin to work with this particular scaffolding/generator. Our application has gotten fairly robust (200~ JS files) so I was really looking forward to being able to use this plugin to automate what I believe now has to be done. Correct me if I am wrong, but my only option for conversion at this point is to manually update every single file so that it exports via commonJS module syntax. I essentially need to do a module.exports = { whatever; } and then make sure that in addition to that, every .js file includes the appropriate require()s. That sound about right?

from angular-webpack-plugin.

To make it work with existing tools, you would have to update every file to define dependencies. You can use commonJS format for that, or you can use this plugin with lines like:

angular.module('foo", ["foo.controllers", "foo.services"]);

Or you can mix and match - that's the real beauty of webpack. Some people prefer to have their leaf files export services or controllers as functions/objects and then wire them up in a module file. I've tended to lean towards one angular module per file - that's why I wrote the plugin in the first place.

The biggest problem I had was with third-party angular libs that have lots of modules bundled in, they usually need some kind of shim definition.

from angular-webpack-plugin.