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

[rsarky]

I would like to help with this issue. A quick scan of the conversation till now tells me that --minimal flag needs to be implemented to have minimum bloat in the project. (Less testing frameworks etc.)
Are there any further pointers?

[LoganDark]

Just one. Preferably it would have no testing frameworks - no Protractor, no Jasmine, no Karma, no .spec files, no TSLint, etc. A minimal project should only have the bare minimum. :)

[rsarky]

@LoganDark Understood.
Isn't minimal open to interpretation here?
What should a bare minimum project contain?
I guess this needs some discussion?

[LoganDark]

It's been 'needing discussion' for a long time. There have been many discussions, but everyone keeps pushing it off because they didn't see their opinion in there.

The general consensus (the opinion people don't like) is that people want a project that doesn't take up 200+ MB with no modifications. Part of that would be removing all the testing frameworks. Every little bit counts, but I don't want to lose any features of Angular. I just want to lose stuff I don't need and won't use and have to spend effort removing with every new project.

[rsarky]

@LoganDark Makes sense. I will try to open an initial PR and then we can have further discussions over that. Are the maintainers okay with this?

[LoganDark]

I'm sure they'll understand.

[hansl]

We just had a meeting internally and we I'm going to work on re-enabling this flag today.

Just a clarification on the need discussion label; we have those discussions normally twice a week, but if work planning takes over these discussions may happen once a week. So timing may matter; if we put the flag on the day we have those discussions, it could be a week before we actually talk about it and make a decision.

[LoganDark]

Okay, thanks.

[rsarky]

Hey @hansl.
I am looking to come onboard and would love to start with this.
Would you be willing to guide me?

[hansl]

@LoganDark Could you clarify what you mean by this?

The general consensus (the opinion people don't like) is that people want a project that doesn't take up 200+ MB with no modifications.

What does having a large node_modules prevent you from doing or what kind of inconveniences does that do?

[hansl]

@rsarky I'm going to be on gitter this afternoon, if you want to discuss. But this is time sensitive as the final is in 2 weeks, so I might just actually fix this in 1-2 hours before leaving today.

[rsarky]

@hansl I understand. Give me a day?
I think I will be able to do it in that time.

[LoganDark]

@hansl it's also an opinion I don't like, to be honest - I just want the inconvenience (testing frameworks) out. I don't care about the size personally, but I was being objective in that statement.

[LoganDark]

@rsarky Also, please move the discussion to Gitter or some other IM service. I'm getting an email for every single comment you post here, and you're cluttering up the issue as well.

[hansl]

@LoganDark considering @rsarky is discussing the issue at hand it's fine to keep a trail here. you can mute the conversation if you don't want notifications for every messages.

[LoganDark]

K

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