Repository navigation
[Enhancement] Webpack and friends as alternative for underlying build/bundling system.聽#909
Description
馃悩 Alright its time to address the elephant in the room. 馃悩
Lets talk about Webpack integration
CLI Is incrediballz, but SystemJS is a less-than-desirable and less-than-configuration-friendly experience.
Use Webpack to have an awesome experience for all environments
CLI was built to make rapid development easy and awesome with Angular and I don't think it should stop there. Out of the box, CLI users should have a bundling system in place that automagically handles giving them a production ready bundle of their Angular code that they spent the tireless 20 command lines to boilerplate.
Things should be easy to configure
Additionally, handling external libraries, build configuration, async module loading, source mapping, code splitting, code sharing, beautifying, etc. should be EASY to reconfigure if a user wants to. Currently it isn't.
Shouldn't replace SystemJS
I do not think that we should rid of SystemJS entirely, however I do believe that it is important that we provide an alternative for people to use. (SystemJS has provided very successful for plunks and apps no larger than 300kb)
ng init --use-webpack
Adding a simple flag like ng init --use-webpack might be a tolerable alternative that people would be more than happy to use.
There are great repo's out there for a starting point
I think @gdi2290 @Foxandxss 's starters are community wide accepted examples of multi environment webpack setups that would be perfect as a starting point. Plus when Weback 2 ships from beta, we'll be able to leverage tree-shaking, async module loading, etc.
I can probably help too
I will add to this issue a more concrete proposal on how Webpack integration might be setup at a high level. (Although really the only thing the user should have to do is ad the --use-webpack flag and everything else should feel or work the same.
@Brocco @hansl we can communicate about this more at length but I'd not only like to hear your thoughts, but community thoughts and opinions as well. Doing this integration the right way should pave the way for giving people the option to have other integrations the right way too.
UPDATE: to add requirements.
Requirements
- existing preprocessor support
- less
- sass
- compass (?)
- stylus
- postcss (with plugins?)
- style sourcemaps
- tree-shaking and dead code elimination
- TS2.0? es6 => es5
- Babel?
- tsickle+gcc@advanced?
- cacheable vendors chunk w/ cache busted main app
- fast build and serve
- incremental build and in memory fs cache
- multicore/cluster/forked worker support
- support for existing projects
- migration path (if needed)
- test against test-app
- test against material 2
- 3rd party module support
- should be as simple as
npm installw/ import in app. - CommonJS, CommonJS2, AMD, ES6, UMD
- should be as simple as
- testing support
- karma integration
- configurable karma.conf yet bundle 'protected'
- w/ Istanbul coverage
- e2e w/ protractor
- karma integration
- JS sourcemaps support
- pre/post trans?
- dynamic on demand bundles
-
System.importsupport which creates async dynamic bundle
-
- Routing
- Async Route Handling automagically?
- ngc support
- if not ts.LSH support, build step
- should not be slow
- asset support
- assets copied over in distribution bundle
- automagically resolve images
- if under x size, base64 and inline image
- if over x size, serve asset inside of assets folder
- support for fonts
- inline SVGs?
Activity
SethDavenport commentedon May 25, 2016
+a million. Jokes aside I'm down to help
This is what we've been using for a few months now: https://github.com/rangle/angular2-redux-starter, https://github.com/rangle/angular2-starter
PatrickJS commentedon May 25, 2016
nickroberts commentedon May 25, 2016
Love. Definitely would like to have the option to use Webpack. @TheLarkInn's talk at ng-conf really got my juices flowing. I'm just starting to learn Webpack in more depth, and it seems like a great option.
So far, the SystemJS module loader works great, but seems a bit large (and a little slow) for development purposes.
That being said, I'm really excited about the offline template compiler using Rollup, based on what @robwormald demoed at ng-conf.
Exciting times!
nickroberts commentedon May 25, 2016
Also, I was thinking that this functionality could probably be separated out to a plugin (or addon, as Ember calls it). This plugin could house all of the blueprints that would be needed to get things running.
You can already generate an addon via
ng addon <addon-name>. I'm not entirely sure how useful it is, at least for angular-cli yet, though.Perhaps the
ng new myApp --webpackoption could automatically check for this new addon, and either use it, or fail and provide instructions on how to install it.Just some thoughts...
mattdistefano commentedon May 25, 2016
FWIW I don't care about webpack integration per se, but parity with webpack's feature set would be nice to see. I can't claim much expertise here, but my understanding is SystemJS is actually superior in a couple aspects, namely that it is using a standards(ish)-based module format and loader runtime, and provides an easy path forward to "unbundle" for http2. Webpack 2 may address some of that, but fundamentally it seems like SystemJS is a module loader first, and bundler second, whereas Webpack is a bundler first, and loader second.
That said - I'm coming from a webpack background, and, trying out the CLI a week or two ago, I found myself missing the non-JS loading/dependency tracing that webpack does (i.e. being able to import a SCSS file and knowing that webpack will compile it and add any referenced assets - images, fonts, etc - to my dist output), along with the production build file name hashing. I think SystemJS itself actually supports both features, so this may just be a documentation issue?
Likewise, I logged #893 about this already, but I think HMR is going to be very important (as in, important enough that if webpack supports it and CLI doesn't, lots of devs are going to stick with webpack).
SethDavenport commentedon May 25, 2016
My point of view is that I want a bundler, not a module loader. A module loader might makes sense once HTTP2 is mainstream but I'll believe in HTTP2 when I actually see it. In HTTP1 module loaders are a solution looking for a problem IMO.
The non-JS bundling is actually my favourite feature of webpack. Suddenly with chainable loaders and PostCSS we have a really nice CSS workflow - on par with Babel.
mattdistefano commentedon May 25, 2016
Right, but if you could have dynamic module loading and bundling today + painless unbundling for HTTP2 tomorrow, that would be the ideal scenario, yeah? And from my understanding of it, that's basically what SystemJS does, albeit with maybe some more configuration overhead than webpack. IIRC the CLI is already using the bundling features for prod builds too.
More broadly, I think the point of the CLI, to at least some extent, is to abstract the details of the build tooling, test runners, etc. So that's why I say I don't care about webpack vs. SystemJS vs. whatever - if the CLI can incorporate the useful features of webpack without incorporating webpack itself, that's fine with me.
Foxandxss commentedon May 25, 2016
The problem I see @mattdistefano is that even if the CLI abstract you from System.js / webpack / foo. You still need to configure extra tools for your own needs. There you can't avoid to touch System.js / gulp / webpack.
mattdistefano commentedon May 25, 2016
@Foxandxss Yeah, I'd still expect to have to tweak it to some extent. I guess my point is just that "webpack has some features the CLI lacks today" doesn't necessarily lead to "we must support webpack".
TheLarkInn commentedon May 25, 2016
@mattdistefano Mind you I did say "Webpack and friends". I just believe the most popular bundler and build tool would be a great one to start with.
SanderElias commentedon May 28, 2016
Point is, that in the current situation (read http2 not widely available) bundling is not an option, but rather mandatory. Even in development it's hurting. Compare an systemJS hello-world with an webpack one. The waterfall in the systemJs case does really hurt. Even more if you need to work on a networked connection!
(systemJS 293 resources vs 4 to 5 for webpack)
So, a webpack option for the CLI is something we really need.
Then there is the point that, with so many developers, opinions differ. Are we really in a position that we want to exclude a lot of them, simply because they don't like systemJS?
And while we are on this subject of integrating another loader/bundler/packer/whatever, perhaps it's an idea to cater for future expansions in this area. For example RollupJS is also approaching. And I highly doubt that will be the last invention.
mattdistefano commentedon May 28, 2016
Yeah but, again, there may be ways to solve those problems within the existing CLI tooling. That's what I would like to understand better - how many of these issues can be attributed to fundamental limitations of the CLI's current tech, and how many are really just features that haven't been implemented yet, or bugs that can be fixed?
54 remaining items
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
build: use webpack for building apps.
angular-automatic-lock-bot commentedon Sep 6, 2019
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.