[Enhancement] Overridable webpack config

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.

@TheLarkInn

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.

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.

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.

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.

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

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?

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.

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.

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.

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.

@hansl

@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.

@hansl

@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.

@hansl

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

Hi, all. I solve this problem as follows:

Add my custom webpack.config.js to root, for example:

'use strict';
var ExtractTextPlugin = require("extract-text-webpack-plugin");

var plugins = [
  new ExtractTextPlugin("[name].css")
];

module.exports = {
  context: __dirname + '/src',

  entry: {
    vendor: ['./css/vendor.less'],
    app: ['./css/app.less']
  },

  output: {
    path: __dirname + '/public/build',
    filename: '[name].js'
  },

  devtool: "source-map",

  plugins: plugins,

  module: {
    loaders: [
      {
        test: /\.less$/,
        loader: ExtractTextPlugin.extract("css?sourceMap!less?sourceMap")
      },
      {
        test: /\.(woff|woff2|ttf|eot|svg)(\?v=[0-9]\.[0-9]\.[0-9])?$/,
        loader: 'file?name=fonts/[name]/[name].[ext]?[hash]'
      }
    ]
  }
};

I use /public folder for placement my custom build artefacts.

For integration with angular-cli build flow i added two commands in package.json:

"scripts": {
    "start": "webpack -w & ng serve",
    "build": "webpack -p && ng build -prod",
    ....
}

I think thats pretty simple way for customizing build configuration and maybe there is no need to change cli webpack.config.js directrly.

What do you think, guys?

I am in a somewhat weird position here, because I love how Angular-CLI just works, and I also think that a lot of Webpack's complexity comes from supporting every known frontend idea since the blink tag; something we're in the enviable position to (largely) get rid of with a standardized and fairly opinionated framework like Angular2.

But on the other hand, I am running smack into the CSS issue; I specifically set a project up using PostCSS (CssNext, Autoprefixer and CssNano) in the System.js version, and have so far been blocked from moving to the Webpack version of Anguar-CLI because it would require me to rewrite the CSS.

So from where I am standing, I would love to not be exposed to Webpack, but that would require the PostCSS plugins to be more than a "nice to have" in some future version.

If not access to a fully configurable Webpack config, an exposed—controlled—set of options would be ideal. That would keep the tight CLI intact, but allowing to configure in a controlled manner. Multiple people have mentioned PostCSS, which a good example; additionally, modules like Autoprefixer have configurable options themselves, which are directly tied into the browser support requirements on an app per app basis.

That said, and let's call this playing devil's advocate, the angular-cli source code is of course not black magic as far as the Webpack stuff goes. When applications outgrow the ng build setup, the reference of what the cli is doing is always readily available, i.e., https://github.com/angular/angular-cli/tree/master/addon/ng2/models.

Like Wulfsberg I'm heavily using Sass + PostCSS, and I managed to get that working with SystemJS/Broccoli. I would really like to use rc5 + new router, but not allowing us to modify the webpack config as a temporary measure while you work on a more "angular-cli" solution I'm being prevented to do so. I understand you want a new user friendly approach, but we are being cut out…

@Kunepro

For production app in a medium/large enterprise, I don't think packaging management is a "nice to have". Like @Kunepro , I think we at least need a temporary mesure to be able to customize the way webpack generate the dist files. Like @wulfsberg and @Kunepro we using Sass + PostCSS, but we also want to externalize some libraries like Angular to be hosted in a CDN like site. We're building multiple SPA (one by feature) in our system and don't want to add common libraries into each "bundle.js". @hansl can you plan over a temporary solution before the version > 1.0 ? Thanks!

The angular-cli@webpack already makes use of webpack-merge so I don't see why it would be so bad to ALLOW for the presence of webpack-XXX.config.js in environment then just merge it in if it's there, and don't if it's not.

@wz2b

I'm with @wz2b, @martinbelanger, @Kunepro, @wulfsberg and the rest. Not being able to modify the webpack config is not an option for a production app. It's a requirement. It would be one thing if this was a learning tool only, and if that's the way you're headed, please let us know now.

The cli is great, but if the plan is to make it this stringent and inflexible, I'll start refactoring my app to use plain webpack/systmejs. As @wz2b mentioned, the functionality is almost there, it should only be a couple lines of code. With the fix suggested, this would keep it useable for those who need an easy, "on click and go" solution, and also allow the flexibility for those of us who need it.

I totally get aiming to reduce or eliminate "framework fatigue" because IMO it's one of the biggest barriers to angular - years of screwing around with grunt, gulp, and npm scripts have made me hate tooling.

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.

There are two extremes here though (beginner vs. expert) and as with most things there are a lot of people (I'd argue most) that are somewhere in between. It's for those people that it would be nice to be able to say "You don't need to provide a webpack.config.js but, if you do, we'll take it into consideration."

There's an overwhelming amount of people asking for this.
Not only here, a lot of them don't find this issue and instead ask in gitter, reddit or stackoverflow. I know because thats how I did find this in the end, reading comment after complain, after days of searching for a solution.
I don't know how long it will take you to give us the "definitive version", but like I heard many said: "if this doesn't come out next week, I'm out".
Your behaviour is irresponsible in the regards of those that trusting the Angular team decided to adopt it early.

We understand that everyone is extrenely excited to configure the webpack bits of the CLI. Please please please, understand that we are working on this as we speak. We haven't ignored these requests. Everyone on the team gets the email notifications from this github issue.

If you want an immediate work around like we have mentioned multiple times, you can pull down master to 'hack the CLI' and link it to your project. If you look in the source there is no surprise which files are specific to the webpack configuration.

What would truly be irresponsible is to add a customization feature ahead of implementing the AoT compiler Integration, which is one of the key performance features for ng2.

Regardless we are taking our time on this to ensure that we give you a solution that works for everyone the right way. We respect your opinion and appreciate you genuine concern for wanting people to continue to use the CLI.

@TheLarkInn

@TheLarkInn we appreciate it! Is there any way we can pitch in?

@Iverson

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?

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.

@Kunepro

@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.

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?

@hansl

@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

@hansl

@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?

@hansl

@hansl

Thanks, at least I know that waiting is not a viable option.
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).

@Kunepro

@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.

@bennett000

@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.

@Kunepro

@Kunepro seeking this functionality myself.

@hansl

@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.

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 :)

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

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

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.

@hansl

@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.

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.

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.

Navigation Menu

Repository navigation

[Enhancement] Overridable webpack config #1656

Angular-cli@webpack is awesome

And a default webpack config is a life-saver

But webpack needs to be configurable

You can't please everybody

What then?

One possible solution

`webpack-config.js`

`angular-cli.json`

Summary

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Enhancement] Overridable webpack config #1656

Description

Angular-cli@webpack is awesome

And a default webpack config is a life-saver

But webpack needs to be configurable

You can't please everybody

What then?

One possible solution

webpack-config.js

angular-cli.json

Summary

Activity

SethDavenport commented on Aug 12, 2016

kylecordes commented on Aug 12, 2016

dpsthree commented on Aug 12, 2016

TheLarkInn commented on Aug 12, 2016

adamduren commented on Aug 12, 2016

nikolasleblanc commented on Aug 12, 2016

SethDavenport commented on Aug 12, 2016

SethDavenport commented on Aug 12, 2016

bennett000 commented on Aug 12, 2016

nigel-dewar commented on Aug 12, 2016

nikolasleblanc commented on Aug 12, 2016

nigel-dewar commented on Aug 13, 2016

hansl commented on Aug 16, 2016

nikolasleblanc commented on Aug 16, 2016

Iverson commented on Aug 19, 2016

wulfsberg commented on Aug 23, 2016

emilio-martinez commented on Aug 25, 2016

Kunepro commented on Aug 29, 2016

martinbelanger commented on Aug 29, 2016

wz2b commented on Aug 29, 2016

jimjenkins5 commented on Aug 29, 2016

wz2b commented on Aug 29, 2016

Kunepro commented on Aug 30, 2016

TheLarkInn commented on Aug 30, 2016

itamark commented on Sep 5, 2016

Kunepro commented on Sep 21, 2016

hansl commented on Sep 21, 2016

bennett000 commented on Sep 21, 2016

hansl commented on Sep 21, 2016

bennett000 commented on Sep 21, 2016

martinbelanger commented on Sep 22, 2016

Kunepro commented on Sep 22, 2016

bennett000 commented on Sep 22, 2016

Kunepro commented on Sep 22, 2016

richpeck commented on Sep 22, 2016

wulfsberg commented on Sep 22, 2016

SethDavenport commented on Sep 22, 2016

Kunepro commented on Sep 23, 2016

alexsorokoletov commented on Sep 26, 2016

Matmo10 commented on Sep 26, 2016

muratcorlu commented on Sep 27, 2016

hansl commented on Sep 27, 2016

hansl commented on Sep 27, 2016

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`webpack-config.js`

`angular-cli.json`