Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parse-time deprecation messages are not properly rate limited #2390

Open
ntkme opened this issue Oct 17, 2024 · 4 comments · May be fixed by #2396
Open

Parse-time deprecation messages are not properly rate limited #2390

ntkme opened this issue Oct 17, 2024 · 4 comments · May be fixed by #2396
Assignees
Labels
bug cosmetic Doesn't affects CSS semantics

Comments

@ntkme
Copy link
Contributor

ntkme commented Oct 17, 2024

$ npx sass --version
1.80.0 compiled with dart2js 3.5.3

$ npx sass --no-verbose node_modules/bootstrap/scss/bootstrap.scss 2>&1 | grep 'Sass @import rules are deprecated and will be removed in Dart Sass 3.0.0.' | wc -l
      87

When compiling latest bootstrap, the same @import deprecation is printed 87 times, where it should only be printed 5 times and then get summarized.

@ntkme
Copy link
Contributor Author

ntkme commented Oct 17, 2024

/// Wraps [logger] to process deprecations within an ImportCache.
///
/// This wrapped logger will handle the deprecation options, but will not
/// limit repetition, as it can be re-used across parses. A logger passed to
/// an ImportCache or AsyncImportCache should generally be wrapped here first,
/// unless it's already been wrapped to process deprecations, in which case
/// this method has no effect.
static DeprecationProcessingLogger wrapLogger(
Logger? logger,
Iterable<Deprecation>? silenceDeprecations,
Iterable<Deprecation>? fatalDeprecations,
Iterable<Deprecation>? futureDeprecations,
{bool color = false}) {
if (logger is DeprecationProcessingLogger) return logger;
return DeprecationProcessingLogger(logger ?? Logger.stderr(color: color),
silenceDeprecations: {...?silenceDeprecations},
fatalDeprecations: {...?fatalDeprecations},
futureDeprecations: {...?futureDeprecations},
limitRepetition: false);
}

@jathak This seems to be a deliberate choice but I'm afraid that this is way too noisy for large framework like bootstrap.

@ntkme ntkme changed the title Default non-verbose logger is not summarizing repeated deprecation messages Default non-verbose logger does not summarize repeated import deprecation messages Oct 17, 2024
@nex3 nex3 added bug cosmetic Doesn't affects CSS semantics labels Oct 17, 2024
@nex3
Copy link
Contributor

nex3 commented Oct 17, 2024

I agree that we should make sure this case uses a repetition-limiting logger. Probably from the CLI, we should manually construct a shared logger—or if we're running in watch mode, a separate shared logger for each batch of events.

@ntkme
Copy link
Contributor Author

ntkme commented Oct 17, 2024

Probably from the CLI, we should manually construct a shared logger—or if we're running in watch mode, a separate shared logger for each batch of events.

In fact, we have the very same issue in both CLI and API due to the DeprecationProcessingLogger inside ImportCache is hard coded with limitRepetition: false. The JS API specifically mentions the behavior of verbose option here: https://sass-lang.com/documentation/js-api/interfaces/options/#verbose

By default, Dart Sass will print only five instances of the same deprecation warning per compilation to avoid deluging users in console noise. If you set verbose to true, it will instead print every deprecation warning it encounters.

nex3 added a commit that referenced this issue Oct 17, 2024
See #2390. This is definitely not the correct long-term
solution—we only want to limit repetition in the context of a single
batch of compilations, and this doesn't always respect `--verbose`—but
it's way better to display too few deprecations than too many.
nex3 added a commit to sass/sass-spec that referenced this issue Oct 17, 2024
These are not intended to reflect the correct behavior, but rather the
fact that we need to limit the amount of repetition univerally until
we have time to find a proper solution to the underlying bug.
nex3 added a commit to sass/sass-spec that referenced this issue Oct 17, 2024
These are not intended to reflect the correct behavior, but rather the
fact that we need to limit the amount of repetition univerally until
we have time to find a proper solution to the underlying bug.
nex3 added a commit that referenced this issue Oct 17, 2024
See #2390. This is definitely not the correct long-term
solution—we only want to limit repetition in the context of a single
batch of compilations, and this doesn't always respect `--verbose`—but
it's way better to display too few deprecations than too many.
@ntkme ntkme changed the title Default non-verbose logger does not summarize repeated import deprecation messages Parse-time deprecation messages are not properly rate limited Oct 17, 2024
@nex3
Copy link
Contributor

nex3 commented Oct 17, 2024

After consulting with @jathak, the current plan here is to move away from emitting any deprecation warnings at parse time at all. Instead, the parser will accumulate a list of deprecations and attach it to a hidden field in the Stylesheet object, and the evaluator will then emit those warnings when the stylesheet is loaded. This will allow us to avoid needing to have the ImportCache handle a logger at all.

As a side effect of this, we can (Dart-level) deprecate the logger parameter to the ImportCache as well as various parse functions.

@jathak jathak linked a pull request Oct 18, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug cosmetic Doesn't affects CSS semantics
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants