Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
larssn opened this issue May 22, 2018 · 21 comments

Comments

Projects
None yet
@larssn
Copy link

commented May 22, 2018

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

This comment has been minimized.

Copy link
Contributor

commented May 22, 2018

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

@filipesilva

This comment has been minimized.

Copy link
Member

commented May 22, 2018

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

This comment has been minimized.

Copy link
Contributor

commented May 22, 2018

@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

This comment has been minimized.

Copy link
Member

commented May 22, 2018

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

This comment has been minimized.

Copy link
Author

commented May 22, 2018

@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

This comment has been minimized.

Copy link
Member

commented May 22, 2018

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 has been minimized.

Copy link
Member

commented May 22, 2018

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

@michael-letcher

This comment has been minimized.

Copy link

commented May 22, 2018

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

This comment has been minimized.

Copy link

commented May 30, 2018

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

This comment has been minimized.

Copy link

commented Jun 2, 2018

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

This comment has been minimized.

Copy link

commented Jun 7, 2018

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

This comment has been minimized.

Copy link

commented Jun 20, 2018

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

@darkguy2008

This comment has been minimized.

Copy link

commented Jun 20, 2018

@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

This comment has been minimized.

Copy link
Author

commented Jun 22, 2018

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

This comment has been minimized.

Copy link

commented Jun 25, 2018

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

This comment has been minimized.

Copy link

commented Jun 28, 2018

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

@kavi87

This comment has been minimized.

Copy link

commented Aug 2, 2018

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

@001123

This comment has been minimized.

Copy link

commented Aug 15, 2018

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

@Pringels

This comment has been minimized.

Copy link

commented Nov 1, 2018

+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

This comment has been minimized.

Copy link

commented Apr 16, 2019

I used angular-builders to patch Angular 7 configs.

@klemenoslaj

This comment has been minimized.

Copy link

commented Apr 16, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.