[Feature Request] A hook file to customize webpack config.

[larssn]

Intro
We dearly need a lightweight way to customize the internal webpack config file, so advanced users can tweak it, and still use the CLI, without having to eject. The current approach of having to eject causes a huge amount of overhead (also for the CLI team it seems). In NG5, we personally had 4 different fully complete webpack config files, to satisfy our dev environment, which was getting out of hand.

Since you can't eject in NG6, you currently have people rewriting node_modules files, to do some simple customizations. See https://gist.github.com/niespodd/1fa82da6f8c901d1c33d2fcbb762947d

Proposal
Doing an ng serve/whatever calls a hook file, where you can customize the webpack config related to the current ng command.

function webpackHook(config) {
   config.node = {
       crypto: true,
   }

   const args = require('yargs').argv;
   if (args.stats) {
    try {
         console.log('Adding Stats Plugin');
         const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
         config.plugins.push(new BundleAnalyzerPlugin());
      } catch (e) {
         console.error('webpack-bundle-analyzer not installed - `npm i webpack-bundle-analyzer --save-dev`');
      }
   }

   return config;
}

A hook file like this would probably remove the need to eject in the first place.

Was originally posted here, where it seemed to gather support: #1548 (comment)

[vincentjames501]

Thumbs up and upvote! Would probably eliminate most peoples need to eject at all as I know it would us.

[filipesilva]

I'm really sorry that I have to close this issue but this is still a duplicate of #1656, and our stance on this topic still has not changed. If it changes, we will announce it on that issue.

[vincentjames501]

@filipesilva Any word on the "addon" system that's been in the works for 2 years?

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.

[filipesilva]

The new workspace is part of that addon system. It provides extension points from where you can change what ng commands do.

The upcoming eject (#10946) leverages that. The plan is that doing ng eject will give you a hand-written webpack config, and that then doing ng run project-name:build-webpack runs that config.

If you replace the ejected target name (this is the keys inside the architect entry in your angular.json file) from build-webpack to just build, then ng build will run your webpack config instead.

[larssn]

@filipesilva But ng eject has always given you a 'hand-written' config file. It did - and still does - add a huge amount of potential maintenance.

In NG5 our workflow was thus: Ever so often, we'd have to do 4 separate ng ejects in a new project, some with --aot --sourcemaps, some with --prod, and so forth. We'd then do a git diff of our existing webpack config files, to see how you guys had changed the internals of the CLI. And it did change quite often. This was a non-trivial amount of work; just to be up to date and without fear of our build breaking after an npm update.

The argument @hansl comes forth with in that topic doesn't really hold water IMO. You argue that you don't want to expose the novice user to complex subjects like a webpack config file. But then how is doing an optional ng eject somehow less complex than an optional hook file? It simply isn't. I hope this decision doesn't come down to politics alone. :)

I can only beg of you to bring this issue up again whenever you have an internal meeting. I cringe by the thought of having to ng eject again in the near future. 😞

[filipesilva]

The webpack configuration you would get in CLI 1.x when doing ng eject was never handwritten. It was serialized from the internal objects, and templated. To be honest it was very hard to keep it working properly on our side as well.

The CLI 6.x eject will give you a simple webpack config that does the main things we do inside the CLI. The idea there is to never eject more than once. You should be able to eject, do whatever you need with that config and build using. Meanwhile you can still build with the default Angular CLI build system. These will be separate but not mutually exclusive.

[clydin]

This comment from an eject related issue is relevant here as well: #10945 (comment)

[michael-letcher]

Disappointing to see the Angular team rejecting collaboration and would rather close tickets and lock them than keep an open ticket on the subject allowing for discussion...

There is a reason that this #1656 (comment) is so heavily rejected by the community.

[RyRy79261]

How is this issue still going on.

I've spent 2 days reading through post starting in 2016 relating to this issue. There needs to be a better way than simply running a post install patch directly into the node module to allow for minor webpack tweaking.

[JonnyBGod]

I understand the amount of maintenance problems that would come from exposing the full webpack.config. But I also think that it is totally nonsense to need to ng eject and then have to maintain it myself just to be able to add and extra webpack loader.

Why not compromise a bit and expose some parts of the webpack.config with a simple plugin/hook system?

Also you could easily do this while throwing a "At your own risk!" warning.

ng eject should be considered just for edge cases and angular/cli should be open for minor extensibility. What you are saying now is that we stick to your idea of what we can so or move away from the CLI.

[darkguy2008]

I can't believe that we're in 2018 and this issue is still alive. I'm finding myself in the need to use google-fonts-webpack-plugin and without ejecting I can't do it.

I fail to see why it's so complicated to use webpack-merge and merge it with whatever file the user can specify through the CLI and get it done. 2 years on this? come on... I used to do this almost daily in all my projects, and they were easily overridable, however, I'm being forced to use the CLI and I can't find a way to override just a specific portion of the config (adding a plugin).

Come on, this is basic stuff, give the user a choice or the possibility to do so.

[urish]

Check out angular-cli-customizer - did the trick for me

[darkguy2008]

@urish Awesome!! Exactly what I was looking for! Someone give these men a beer and include this as a core functionality in the CLI. I can't believe someone had to hack it... still, great.

[larssn]

There's also this unofficial plugin, that does what I initially requested:
https://github.com/Angular-RU/angular-cli-webpack

I really still would like official support though...

[sublimator]

Yes, what a pita, I just upgraded an old app, which suddenly stopped working due to node: false being added, then I realized I have to...

Ugh

[pawelkondraciuk]

It would be so great to have an option to customize angular-cli config with webpack.config.js file, just like webpackMerge

[kavi87]

Please, people need to merge advanced configuration in the cli, we're not in kindergarten here.

[001123]

Please add soon!
VUE, REACT can easy add webpack config.

[Pringels]

+1

The recent upgrade to angular 7 completely broke coverage reporting in our monorepo setup. The response from the Angular team was that it was "by design". All I need to do to fix this is to disable a single line in the @angular-dekit/build-angular test webpack config.

I'm seriously starting to consider switching my team over to Vue.js for future projects. I've encountered many requests like this one where the default response always seems to be "Deal with it. Issue closed."

There has to be some middle ground here :(

[keaukraine]

I used angular-builders to patch Angular 7 configs.

[klemenoslaj]

I used angular-builders to patch Angular 7 configs.

This works pretty nice, but only for the applications. If you have multiple libraries in your repo consumed by the application, then custom webpack builder will not help.

Referenced custom webpack builder hooks only into @angular-devkit/build-angular builder, which is used to build applications.
Libraries use @angular-devkit/build-ng-packagr builder, which I think is rollup undedr the hood even.

So yea, in a bit more advanced situation we have no workaround at all.

[angular-automatic-lock-bot]

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