`--minimal` flag does nothing

[hansl]

We should get styleguide guidance for what the --minimal flag should act on 6.x / 7.x. Or just implement it the way it was before.

[marzsocks]

As of now an empty Angular project is 275mb without a line of project code! It's insane to assume every project needs to be this bloated.

[LoganDark]

@marzsocks especially with a ton of testing frameworks, that alone equates to 14 vulnerabilities and 196 packages.

How to uninstall testing bloat:

npm un -D codelyzer jasmine-core jasmine-spec-reporter karma karma-chrome-launcher karma-coverage-istanbul-reporter karma-jasmine karma-jasmine-html-reporter protractor @types/jasmine @types/jasminewd2 tslint

You read that right. These are all the testing frameworks Angular CLI has installed by default. And this is the ENTIRETY OF ALL VULNERABILITIES IN THE APPLICATION.

[hansl]

@marzsocks @LoganDark you'll be happy to know that we don't have any vulnerability listed in npm audit as of 6.2.3 and the latest 7.0.0 beta.

[LoganDark]

@hansl it's great to know that those few forgetting to install all the testing frameworks won't be vulnerable, however, those testing frameworks (hopefully!!) aren't in use unless you specifically invoke them, so the vulnerabilities weren't that severe anyway.

That still doesn't solve the root issue here. See @marzsocks' comment above.

[hansl]

As of now an empty Angular project is 275mb without a line of project code! It's insane to assume every project needs to be this bloated.

Although I agree that smaller project sizes are nice, I think there's a lot of disagreement over what bloated mean. 280MB of node_modules during development is really not large.

The size of node_modules doesn't really impact much, outside of bandwidth and disk size for the developer itself, which I would assume are not that limited. The final size of Angular when bundled and minimized went down significantly with every major release, and this is the size that really matters for end users (along with TTI).

In any case, this issue is about re-implementing the minimal flag.

As a workaround, we moved a lot of dependencies over the time to the project itself, but none of this code affect the final application. You can always ng new --skip-install then remove the dependencies you think you won't need. The default path will always contain all testing infrastructure we fully support, as this is the best practices we want to push forward.

[LoganDark]

In my opinion, forcing 3 (or more) testing frameworks on people isn't a best practice, but it doesn't matter to me, only adds around 5 minutes of my time wasted removing them all. Not that horrible compared to the weeks it takes to create a good project.

[marzsocks]

• By "best practice" you assume every angular project is an enterprise style solution that needs test frameworks. Bad to assume that.
• Surely "best practice" can still mean including test frameworks by default, and allowing a switch to not include.
• Manually removing dependencies that are not used is not a sound "best practice" approach.
• Many developers are interested in a light weight, quick setup framework. Developers will quick switch to something less controlling if it takes 15 minutes (because you have to remove things) and 250mb for each project setup.

Sorry but saying its "best practice" is only true in a certain professional context. Think of the millions of home-style websites, or educational projects out there that don't need all this jazz.

By the way, I am sorry to hear that the mindset is that "250mb of node_modules is not that large and you 'assume' is not a problem on developers computers". Perhaps don't 'assume' as it's a big wide world out there. You should strive to be as small and light weight as possible - even in SDK environment. 250mb of JS is massive.

[LoganDark]

Sorry but saying its "best practice" is only true in a certain professional context. Think of the millions of home-style websites, or educational projects out there that don't need all this jazz.

Educational projects usually go with the (One True "Best Practices Ever"™)++ and use 29 testing frameworks with 3 GB of documentation for something like a simple to-do list app.

The fact that such a seemingly trivial issue compelled me to spend so much time here trying to get it changed should be enough proof that, in certain cases, test frameworks are not always desired, like @marzsocks' fourth bullet point.