Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Partial fix for #633.
This restructures deprecation warnings into a class that gives each deprecation an identifier and structures the warnings themselves primarily based on the instance variables of that Deprecation.
This supports the core use case of making a deprecation fatal from the command line, but I'd like some feedback on the general approach before finishing this PR (mainly adding support to the Dart API and updating any sass-specs with warnings that were tweaked as part of this).
My main questions are:
Deprecation
and the parameters forDeprecation.message
were mostly just based on what was necessary to replicate the existing warnings in a structured way. Are there any that don't make sense, or additional properties that should be added? Also, are there any deprecations without aremovedIn
version that should have one?withWarnCallback
to include anerror
function to allowDeprecation.warnOrError
to work? I'm more confident in the former, but I'm less sure about the latter.--fatal-deprecation
flag), or shouldDeprecation
be exposed as part of the public API?