Replace custom webpack config with angular-cli's internal build

Overview of the issue

Feature request. Angular-cli has a perfectly good webpack setup. This is continously improved upon and follows best practice for angular projects. JHipster’s webpack config is not compatible and the builds it produces differs very much from what angular-cli produces. Standards are important, and best practices should be enforced. A great product like JHipster should be a role-model for how a good solution structure should be.

Motivation for or Use Case

JHipster states that it is compatible with angular-cli, but this is limited to angular-cli blueprints like generating new components. One cannot build a jhipster project using angular-cli and therefore one cannot take advantage of the build optimizations the Angular team has developed, nor the latest features provided by the angular team.

Suggest a Fix

JHipster already has all the files required from angular-cli. I propose that

• the webpack folder be removed from the generated files,
• package.json include the standard angular-cli scripts like ng build and ng-serve (with proxy to backend off course)
• The frontend jhipster produces yields errors when built using angular-cli. This needs to be fixed.

JHipster Version(s)

This applies to all jHipster versions > 4.0.0

• Checking this box is mandatory (this is just to show you read everything)

[mraible]

FWIW, I spoke with @mgechev from the Angular team last night. He’s interested in helping make Angular CLI work with JHipster. He’s willing to do a call, but I told him it’d probably be more appropriate for us to compose a list of issues we have and see if Angular CLI has extension points to solve them.

[jdubois]

I’m closing this as nobody has volontered to do this.

Please note that I would like to follow Angular CLI’s Webpack build, but:

• What Angular CLI does is very, very basic compared to what we do, and that might not be enough for our needs.
• I’m certainly not going to use this as it is a “standard”. There’s no standard here, just the Angular team forcing everyone to follow their path. We started before them, and are also a very popular code generator, we are as “standard” as them. A “standard” is what Java EE is.
• Let’s not blindly follow the Angular team path: Angular 2+ is far from being a success, and from my point of view they also failed their router and i18n implementation.

-> once again, I’d rather use Angular CLI’s Webpack build, as this would be less work and trouble for us, but I don’t think this is a priority. That’s a lot of work and there are also some drawbacks. We are working on React support, and soon on VueJS support, so unless someone steps in and decides to do this, this will not be done anytime soon.