Add configuration to allow --quiet-deps to be passed to Dart Sass

[penfold]

🚀 Feature request

Dart Sass is throwing lots of deprecation warnings for 3rd party packages. The Dart Scss team has added a flag to silence them.

sass/dart-sass#672

Is it possible to have a configuration flag in the ng cli to pass through flags to Dart Sass?

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• extract-i18n
• run
• config
• help
• version
• doc

Description

(see above)

Describe the solution you'd like

(see above)

Describe alternatives you've considered

Not sure of any other options.

[alan-agius4]

This feature is not available in the Node API. See sass/dart-sass#672 (comment). That said, there is a similar feature which in the Node API sass/sass#3065.

It very unlikely that we want to increase the API and provide this feature to turn on/off this behaviour.

Possibly we can turn on quietDeps, although I feel like this would cause other issues down the line, since warnings will not be displayed, consumers of the libraries will be unable to report these warnings to the library author. Eventually these warnings will turn to fatal errors and there would be no way to suppress them.

Will bring up this issue during our next team meeting and see what the other team members think.

[bordecal]

@alan-agius4 Perhaps instead of setting this particular option only, might you consider a mechanism where the consuming project could supply the core of a Sass rendering options object that could enhanced by the builder for use when invoking Sass? That would help with temporary suppression of the deprecation warnings that are the immediate problem in this issue, as well as providing potential future extensibility that might be difficult to predict today.

[alan-agius4]

Following a discussion during todays’ team meeting we decided that we should move forward and turn on quietDeps.

[elektronik2k5]

@alan-agius4 can you please share the rationale of this decision? Personally, I'd rather see warnings and be aware of them (so I can take action) rather than have them muted and later discover deprecations when upgrading.
I mean, if these are muted, then at least allow overriding that setting, so people can opt in to see them.

[alan-agius4]

@elektronik2k5,

The main reasons why we decided to go with this approach is

• Such warnings are not directory actionable by the consumer of the library.
• It should be the responsibility of the library to have integration tests to validate that their Sass is not producing warnings/errors.
• These warnings can be pretty noisy when having a lot of components which can result in missing actionable deprecations which are caused by your code.
• I can see that we can allow these to be unmuted, via the --verbose flag.

[penfold]

Thank you for the fast turnaround. I'm looking forward to seeing the issues in my code again instead of them being hidden amongst others that I can't control.

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