[Enhancement] Overridable webpack config

[nikolasleblanc]

Angular-cli@webpack is awesome

With webpack on board, angular-cli is looking like a seriously viable toolset for developing and building production ready applications.

And a default webpack config is a life-saver

Webpack's not exactly a breeze. Having default webpack configs ready to go the second a developer creates a project saves them a lot of time and energy.

But webpack needs to be configurable

Once that project's spun up and begins to take form, that developer may want to tweak the webpack config. They may want to add this loader, and that loader, and they may have opinions about how it should be bundled for production.

You can't please everybody

To bloat the base webpack configs, one PR after another, with each individual's particular project need is unsustainable.

What then?

When a developer needs something that the default won't be able to provide, they might be inclined to break off on their own, leaving the benefits of angular-cli aside.

Why not allow the ease of angular-cli to coexist with the configurability of webpack?

One possible solution

webpack-config.js

webpack-config.js looks for the following config files, based on the current environment.

• weback-build-common.ts
• webpack-build-development.ts
• webpack-build-production.ts
• webpack-build-mobile.ts

Using angular-cli.json, the developer could point to environment-specific webpack configuration overrides.

angular-cli.json

angular-cli.json is already storing paths for karma configs, protractor configs, and tsconfig, why not let it also store webpack configs?

{
  ...,
  "e2e": {
    "protractor": {
      "config": "config/protractor.conf.js"
    }
  },
  "test": {
    "karma": {
      "config": "config/karma.conf.js"
    }
  },
  "webpack": {
    "development": {
      "config": "config/webpack.dev.conf.js"
    },
    ...
}  

If webpack-config.js then checked angular-cli.json to see:

• if an override path has been provided, and
• if a file exists at that path

...it could load the override config instead of the default config.

Summary

This solution offers the developer the option of using default webpack configs to get rolling, as well as the ability to override those defaults once their project begins to show unique requirements, with the smallest possible footprint on the base library.

It also allows the developer to stay in sync with the angular-cli library without having to eject from it, and allows the default configs to continue to stay relevant.

[nikolasleblanc]

https://github.com/nikolasleblanc/angular-cli/tree/Fe-Webpack-Overrides

Here's an implementation of my proposed solution. No longer able to access the webpack branch of angular-cli, so can't submit a PR.

[TheLarkInn]

The webpack branch is actually merged into master. So you can do that there. Also keep into consideration how we currently have webpack using the nodeAPI and tied into the the cli command process. All of these things should be thought about. This is a pretty complex feature in my opinion, and will take some work, so if we propose this, I want it well vetted.

[nikolasleblanc]

Works for me. Done for the night but will submit a revised PR in the morning.

[nigel-dewar]

the proposal from @nikolasleblanc sounds really good. I'd love to see this in action.

[hansl]

Sorry but we will not expose the webpack confit for various reasons. An addon system is being designed that would allow such a thing but for the time being we won't expose it.

[nigel-dewar]

fair enough. looking forward to it.

[nikolasleblanc]

@hansl, can you elaborate on a) your concerns about exposing the config and/or b) your proposal for the add-on system?

This seems to be a feature in high demand and pulling back the curtain on your plans so others could help out or focus their own efforts more to your vision may help accelerate their implementation while taking some of the load off your plate.

[SethDavenport]

I have to say, I personally like webpack for two reasons.

1. It's really good at bundling, and
2. it's very configurable.

The webpack CLI implementation currently provides the value of (1) but ignores (2). I'm very happy with the progress that's been made, but the reality for me is that without (2) it's only halfway there.

I like the default config, a good set of defaults is really important. However those defaults should not be locked. Opinionated is fine as long as it's not overly prescriptive.

So to @nikolasleblanc's point, some insight into your goals and rationale for this decision would help us all come up with the design proposal the community needs.

[kylecordes]

I think there is ample good reason for the CLI team to be cautious about webpack configuration extension. This configurability is both a great strength and a great weakness of the tool.

Others above have praised the value of configurability, no need for me to repeat that.

The weakness comes in with what the community does with it. I have worked with various teams at companies large and small who have created monstrosities of webpack configuration. They do this because they must to survive and make their project work, but it is not a good thing.

The configurability leaves too much room for idiosyncrasies where there should be conventions. By keeping this configurability limited, there is an opportunity to create pressure on both project authors, and more importantly library authors, to build their projects and libraries in a way that they "just work" with a reasonable common default configuration. Lacking that pressure, what I most commonly see is that each time another library is added to a project, the project's webpack complexity escalates further, and eventually for a project of substantial size, it is necessary for one or more of the very most capable people on the project team to devote extensive brainpower to somehow wrangling the webpack configuration to support the requirements of a pile of libraries plus project idiosyncrasies all at the same time.

To get a tiny flavor of this, just spend a few minutes searching the web, looking at all the advice out there of mountains of configuration to copy paste into your webpack configuration to make scenario X or library Y work. Then imagine yourself as someone who is not yet a webpack expert, attempting to divine which bits to copypaste, which bits to ignore, and how to combine those results for six different libraries you are trying to use together on a project.

I don't know if this problem is solvable, I don't know if it is feasible to create enough conventions to avoid the need for each project to have an intricate snowflake of webpack configuration. But it is valuable and worthwhile and wise of the Angular CLI team to at least have the goal of taming it.

[nikolasleblanc]

To assume that one webpack config is the right one seems a disservice to it, and is it really angular-cli's responsibility to save people from their own configuration?

The defaults can certainly ensure that those unfamiliar with webpack can be protected from themselves, but the ability to override those defaults ensures that those that are familiar with webpack can still reap the benefits of their particular config along with those offered by the cli.

[SethDavenport]

@kylecordes Perhaps. But at what cost? Flexibility is what allows a healthy dev community to innovate. Angular-CLI is in a privileged position where its choices may end up constraining a lot of people. This is a concern to me.

For instance - I now am forced to consider going back to SASS, which we abandoned a year ago, simply because the CLI makes me. Why is a JS tool effectively dictating my CSS strategy to me?

But ultimately that's just a symptom. I am cool with opinionated defaults. I am not as cool with prescriptivity.

[kylecordes]

I'm not saying there should be no configurability, I'm just acknowledging that the team is wise to think about some ideas other than just opening it up wide.

But realistically, if we want full webpack configurability, why use CLI? Why not just use Webpack? We can go grab a webpack starter off the web, copy it into a project, and go. I looked at one of them a couple of weeks ago (sorry, I forget which) and with it a project starts out with about 800 lines of webpack configuration, before we start editing it for project needs and to accommodate the needs additional libraries.

I suspect that CLI is going to be extremely popular among small to medium-size projects, particularly those that are willing to adopt its conventions, and that it may need to optimize for these cases. I think for larger projects, enterprise projects, many of them will start with CLI, build some good project momentum, then eventually dropped it and switch to their own build process, webpack configuration, etc. I don't think that is a failure - it would mean CLI helps projects adopt Angular and become successful with it.

Anyway, these are just my thoughts, inferred from watching all of this from the outside. I'm not on the core Angular or CLI team, I'm just out here in the woods working on training material, example projects, and production customer projects. Maybe one of the core guys can chime in with a more official stance, when they are ready.

[nikolasleblanc]

But realistically, if we want full webpack configurability, why use CLI?

Well, for all the other benefits that CLI offers. Lack of configurability of the webpack config, on a cli that moved from systemJS to webpack, is what ultimately will force those on larger projects to branch off.

My first inclination upon running ng create was to update the webpack config, so imagine, I didn't even make a small or medium sized project before I considered branching off. I hadn't even started.

It's not necessarily a failure that people may branch off, but it shouldn't be an acceptable outcome either. The community seems eager to adopt CLI for their entire workflow, and the lack of a customizable webpack config is really the only thing preventing them from doing so.

[e-schultz]

But realistically, if we want full webpack configurability, why use CLI? Why not just use Webpack?

Because of the features the CLI provides ...

• Generating Components, Directives, Pipes and Services
• Generating a Route
• Creating a Build
• Build Targets and Environment Files
• Bundling
• Running Unit Tests
• Running End-to-End Tests
• Deploying the App via GitHub Pages
• Linting and formatting code
• Support for offline applications
• Commands autocompletion

Some pretty compelling reasons to want to use the CLI.

The CLI is using postcss, and one of the nice features about postcss is their plugin system, as there is a rather extensive set of plugins that you could use.

The postcss plugins that we frequently use are postcss-import, postcss-cssnext and cssnano.

If there is a reservation about allowing configuring the webpack config and exposing it, what about a means of allowing people to register the postcss plugins that they would like to use?

{
  ...,
  "e2e": {
    "protractor": {
      "config": "config/protractor.conf.js"
    }
  },
  "test": {
    "karma": {
      "config": "config/karma.conf.js"
    }
  },
  "postcss": {
    "development": {
      "plugins": "config/postcss.dev.conf.js"
    },
    ...
} 

Or is the use of postcss an implementation detail that you are looking to protect developers from?

[TheLarkInn]

For instance - I now am forced to consider going back to SASS, which we abandoned a year ago, simply because the CLI makes me. Why is a JS tool effectively dictating my CSS strategy to me?

@SethDavenport you also can use Less, Stylus, PostCSS (no plugins yet) out of the box just like you use SASS. Unless there is something i've missed. By default right now all of the above are possible.

Also I'll try to followup with some of this discussion later today.

[SethDavenport]

Thanks @TheLarkInn - yes I took a look at the existing source. SCSS, Less and Stylus are brought in as PostCSS plugins. What I'm looking for is a different set of PostCSS plugins: CSSNext & family.

@kylecordes you raise reasonable points. On the topic of starting with the CLI and then rolling your own config once the project gets large, that's not a bad idea. I can imagine something along the lines of create-react-app's "eject" feature. In my case however I run into an issue from the first line of CSS that I write.

To be fair, I have been rolling my own webpack configs since Angular2 beta.1 and will likely continue in the short term.

However increasingly I'm fielding questions from clients along the lines of "why aren't you using that official angular-cli thing"?

If I'm wrong, and the angular-cli is not intended to be the 'official way to do Ng2' then of course they should implement whatever they like :)

On the other hand, angular-cli's apparent positioning as the 'official way to do Ng2' incurs a certain level of responsibility for flexibility IMO. The alternative is undesirable constraints on the community.

[kylecordes]

I totally hear you on the part about "official". This CLI is not just "a" CLI. It is "the" CLI... It lives in the official repository, and resides online at CLI.angular.io. This means it is in a privileged position; there is little reason for anyone else to go about making a competing tool. Such a tool would stand almost no chance of gaining popularity.

I imagine the team probably feels this responsibility pretty heavily: whatever they can come up with, is what the Angular community is going to get. Whatever problems they don't solve, are not going to be solved in the tool "everyone" uses. To the extent Angular succeeds, it will be partly because of their efforts. To the extent people wander instead over to competing non-Angular libraries, it will be partly because of their efforts.

[dpsthree]

One of the largest reasons I can see for keeping the Webpack config hidden is keeping the option open to migrate off of Webpack or takes on some of the functionality in the future. Exposing the internal build tool dependency to end users is a proven path to endless difficulties.

[TheLarkInn]

Not only that but the less we expose to you, the easier it is for us to help you migrate. Just throwing those two cents in. Don't take that statement as me swaying one way or the other officially.

[adamduren]

This would address #1541. Looking forward to whatever solution that's landed on!

[nikolasleblanc]

A default ng create for a new user with this type of functionality in place would be no different than what's currently offered. There would be no additional overhead or inherited difficulty as a result. Only an ability to run a custom webpack config if they wanted to. Any issues encountered by a user running a custom webpack config would be immediately remedied by simply removing said custom webpack config.

Maybe there's something I'm not grasping here, but I don't see this as as much of a risk to angular-cli or to the end user as is being suggested. And with this in mind, why is it not of equal concern that a user can run their own karma config or their own protractor config? Could they not just as easily run into trouble with those?

Can we elaborate on our concerns from a perspective removed from that of a user overwhelmed by a custom config that they themselves have implemented?

[SethDavenport]

I guess I don't see webpack as an 'internal detail' in the sense that I want transparency in my build toolchain. If I'm analyzing a production issue, I want to know and control what's happening at a fairly granular level.

Being 'helped to migrate' is actually a bit scary... it assumes that it's appropriate (or even possible!) for a tool like the CLI to predict production needs for a lot of projects over an extended period of time. In reality I just don't believe there's a one-size-fits-all.

Webpack is complex not because people want it to be, but because the underlying problem space is complex, and because for production tuning flexibility is paramount. In my experience it's a lot simpler than what came before (SystemJS, JSPM, gulp, grunt), but still very flexible.

[SethDavenport]

Nik's proposal is nice because if you don't need to know, you don't even have to see the config. But if you need control, it's available.

[bennett000]

Sorry but we will not expose the webpack confit for various reasons. An addon system is being designed that would allow such a thing but for the time being we won't expose it.

This makes sense to me for a number of reasons. Is there an existing RFC process for CLI features? It would be great to try and leverage all of the different experiences and needs of the broader community. I'm really excited to start simplifying my Angular 2 life with the CLI and flexibility will really help with that.

[nigel-dewar]

The way I see it, and I'm a noob to programming FYI with only 2 years under the belt, if webpack is complex then that is my problem, and my job to sit down, do some hard yards studying it up and learn it. But to me it does not make sense to not do something because it's 'hard'.

If angular cli out of the box runs webpack using a bunch of defaults which makes 'just runs' and which makes it really easy for a noob to get going with it then great! Job done.

But what about when you want to customize, or for the guy who knows how webpack works?

If the creators of angular cli don't provide that flexibility then here is what will happen. Somebody will fork their own solution having all the goodness realized from angular cli 'with' the ability to do the webpack.config , and folks will start jumping onto that. 100% this is what will happen. We're programmers. We got into this game because we want to build things 'the way' we want to build them and we don't accept limitations very easily.

So as we say in aussie, why don't we "give it a shot" and if it doesn't work out the angular cli team can just drop it.

But if it does work out, well that be awesome right!

I can't see the harm in it. Build is a complex area. It always will be. But it's up to the dev to get savvy with it. Angular cli with webpack already has defaults that just work, so the beginner is protected from the pain. But everybody else will be feeling the pain of not being able to customize if there is no way to configure webpack.

Like I said, this will just end up in a fork where somebody adds this feature anyway. It's going to happen. Too many of us want it.

Sent from Samsung Mobile

-------- Original message --------
From: Michael Bennett
Date:13/08/2016 06:02 (GMT+10:00)
To: angular/angular-cli
Cc: nigel-dewar , Comment
Subject: Re: [angular/angular-cli] [Enhancement] Overridable webpack config (#1656)

Sorry but we will not expose the webpack confit for various reasons. An addon system is being designed that would allow such a thing but for the time being we won't expose it.

This makes sense to me for a number of reasons. Is there an existing RFC process for CLI features? It would be great to try and leverage all of the different experiences and needs of the broader community. I'm really excited to start simplifying my Angular 2 life with the CLI and flexibility will really help with that.

You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com//issues/1656#issuecomment-239546246, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AI94WBUO4cz1C_i1H17g2mWu2SvvUrQrks5qfNFpgaJpZM4JitQn.

[nikolasleblanc]

@hansl, this was a fun debate, but bringing it back to its roots, keep up the great work with CLI and let us know if you need help with the add-on.

[nigel-dewar]

@hansl , agreed with @nikolasleblanc , thank you VERY much for all your hard work. We really do appreciate it. What-ever you decide to do, the community as a whole is better off for it. Angular CLI is already a massive leap ahead in productivity and shortens the learning curve for those getting going with Angular 2. Cheers. :-)

[hansl]

Hi, back from vacation. So I just want to jump in real quick here to answer a single question:

@hansl, can you elaborate on a) your concerns about exposing the config and/or b) your proposal for the add-on system?

a. Simply put, we already switched from one build system to another (SystemJS -> webpack). That switch helped us reduce the amount of clutter and we made sure to remove everything that was customized needlessly for the build system.

The major goal of the CLI was always to abstract away the underlying systems, and reduce the "framework fatigue" due to making (in the end inconsequential) decisions that require vast amount of knowledge of the ecosystem. If you're an unexperienced developer that's looking to start in Angular, this is the best tool so far (IMHO) and having to understand webpack in order to use it would only make it worse. If you want prototyping, same; it's the easiest way to start off and hack on something. If you're an expert that wants to use the technology stack we offer, we have enough customization to let you scale up your angular project. If you need to build your Angular2 app with coffeescript, pug and CSS Crush, then you're better off using a seed.

For those custom edge cases, a proper addon system will help. AND make it clear what happens since the user has to take action (install the addon). I'm pretty sure we'll have an example addon that does what you're asking for; load the webpack config from a file. I just don't want that to be included by default because the users won't know how to deal with it. And pointing them to https://webpack.github.io/ or stackoverflow isn't the right answer.

b. unfortunately, I cannot say anything about that. It will be properly designed in the future. This is > 1.0 work.

I'd like to try and find the time to blog about all this in details, but right now we're crushing towards final. Hope you guys can understand.

[nikolasleblanc]

Sounds good @hansl, and appreciate your taking the time to respond.

[Kunepro]

Any vague ETA on this?
Most of my issues are currently blocked by still be using RC4.
It looks like that I have no other choice than to hack the cli.
Can somebody suggest a step process on what I should do? I might not be the first trying this.
Is @Iverson 's guide still working with current beta?

[hansl]

Once we release final, we'll have a clearer list of things to do and roadmap. The earliest ETA I can give is somewhere in 2017. Before the new year is highly unlikely.

[bennett000]

@Kunepro there is another option depending on your circumstances.

I had an older project created with cli@beta.10 or so. Despite my familiarity with webpack it was significantly easier to upgrade the project's Angular version to 2.0 than it was to update to webpack or "hack the CLI".

I'm not really sure that "hacking the CLI" is a viable solution for anyone who's working on a collaborative project due to the complexities it imposes on project setup.

[hansl]

Also, Im curious to know what's so special about your setup that you need access to webpack. What do you need that's not provided?

[bennett000]

@hansl in my case the project I used yesterday contains multiple SPA's so webpack will probably never be a good fit. (BTW I do love webpack and the fact that it's abstracted out of my projects with ng-cli)

In other cases the need is to tap into postCSS so to run tools like CSSNext

[martinbelanger]

@hansl my project also contains multiple SPA and we need to exclude commons libs like angular from bundle (by using CDN for libs). How can I do that without using webpack config?

[Kunepro]

@hansl

1. Thanks, at least I know that waiting is not a viable option.
2. PostCSS. If you can tell me how to use PostCSS (and plugins with config) and compile a sass file with imports and move it into the dist folder during compilation without editing a webpack config all the better. But I've searched and asked for this in Gitter, Reddit and Stackoverflow for weeks and I was unsuccessful.

@bennett000 I'm not following perfectly what you are saying.
Simply put, for me everything is fine as long as I can keep working with PostCSS.
Updating from beta.10 to beta.1X is not the issue (although the more I wait to get back on track the more it will be an headache).

[bennett000]

@Kunepro I had a pretty specific case where that made sense for me. Seemed like it would also make sense for other projects that had modified sys-js configs from that era of the cli.

[Kunepro]

@bennett000 Can you explain the solution you used?

EDIT: Ok, Now I see what you meant.
You are still using system-js instead of webpack, you just updated from angular.RCX to angular2 and updated the necessary files to keep working with system-js.

[richpeck]

@Kunepro seeking this functionality myself.

[wulfsberg]

@hansl Is there any possibility of opening up the PostCSS plugins before that? (Rather than full Webpack configuration)
Since the CLI is already using PostCSS, it seems like it should be fairly easy and non-intrusive, and not having those CSS tools is a major pain point.

[SethDavenport]

PostCss plugin access would help for those of us who have moved away from sass in favour of cssnext.

Even if I go back to sass I would still need the PostCss autoprefixer plugin - I honestly don't know how anyone does modern css without it :)

[Kunepro]

Seeing how the new "style.css" works the possibility to add PostCSS plugins + configuration at this point would perfectly satisfy all my needs.

[alexsorokoletov]

Guys, is there any way to customize webpack config before 2017?

[Matmo10]

For anyone desperate for a configurable webpack setup, I'd recommend this seed project: https://github.com/qdouble/angular2webpack2-starter . This seed also has AOT compilation, which is what is keeping the cli team from spending time adding the webpack config I guess.

[muratcorlu]

@hansl My use cases for a customized webpack config are:

• Adding some more loaders (pug-loader)
• Using HtmlWebpackPlugin to use pug template instead of index.html
• Using git-revision-webpack-plugin and `definePlugin' to inject some version data to my logger automatically.
• Using proxy of webpack dev server.

[hansl]

proxy works already. pug is still being considered but will be after the final 1.0, if anything comes out of it. Custom plugins are a no go for now as well. So really you should be using your own configuration.

[hansl]

Everyone, I'm going to lock this conversation and close this issue as we already said everything there is to say.

Please refer to my comment above (and cf here as well) for the official word from the CLI team.