angular / angular-cli

CLI tool for Angular
https://cli.angular.io
MIT License
26.75k stars 11.98k forks source link

[Enhancement] Overridable webpack config #1656

Closed nikolasleblanc closed 8 years ago

nikolasleblanc commented 8 years ago

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.

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:

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

wulfsberg commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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

alexsorokoletov commented 8 years ago

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

Matmo10 commented 8 years ago

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 commented 8 years ago

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

hansl commented 8 years ago

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 commented 8 years ago

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.