-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Customizable warnings #1978
Comments
As we already have error codes, maybe we should use those to identify warnings (here: |
@guybedford I am experiencing noisy Also If I wanted to help with this feature how might I look into it, considering I am haven't yet spent any time with the source code. |
@skiano if you're interested in working on this that would be really amazing. I'd advise we discuss the basic API first to avoid any wasted development time though. So sketching it out would probably be the first step. Ideally we need this to work through both the API and the CLI, with a pattern for disabling (do we need enabling?) warning codes.
possibly Open to completely different suggestions too. //cc @lukastaegert |
Thanks @guybedford for starting with this sketch. It makes it less daunting to consider contributing. I am not familiar with the C-style precedent. Is |
Perhaps just Also the current project convention is to use camelCase even for CLI flags so perhaps We could even dot warnings too possibly - |
I think following whatever the convention is so far makes sense . So I just cloned everything and started poking around. I imagine it will take some time for me to wrap my head around things. Can I bug you with questions as I go along? |
Sure, happy to help. |
@guybedford I started a PR just to keep the discussion going. |
Instead of turning off any particular warning entirely, can we please have a way to turn off warnings for code in node_modules/? (Or particular warnings in node_modules/, that would be nice too.) I actually wouldn't mind at all being warned of circular dependencies in my own code so I can avoid them, but there's no way I'm going to fork a dependency that is otherwise working perfectly just to make a Rollup warning go away. |
@laughinghan I'd be down for that but we also definitely want to be able to turn off specific warnings... I found this thread because I'm looking to be able to disable "eval" warnings as described here: #2082 |
Hey folks. This is a saved-form message, but rest assured we mean every word. The Rollup team is attempting to clean up the Issues backlog in the hopes that the active and still-needed, still-relevant issues bubble up to the surface. With that, we're closing issues that have been open for an eon or two, and have gone stale like pirate hard-tack without activity. We really appreciate the folks have taken the time to open and comment on this issue. Please don't confuse this closure with us not caring or dismissing your issue, feature request, discussion, or report. The issue will still be here, just in a closed state. If the issue pertains to a bug, please re-test for the bug on the latest version of Rollup and if present, please tag @shellscape and request a re-open, and we'll be happy to oblige. |
An in-file directive would be nice to turn warnings off and turn back on, again. That way, you can disable the warning for specific statements, but leave the rest of the file open to examination:
You could put the 'no-warn' directive at the top of the file to disable the warning for the entire file. A global directive would probably have to be an option to the compiler. |
I may be jumping the gun here, but perhaps the time is coming to think about warnings customization. Warning flags are pretty much a standard for compilers, so I don't see why Rollup shouldn't have them too.
For example, circular reference warnings may be getting noisy - and it would be nice to just add a
--ignore warn-circular
or something like that as a CLI flag to disable that one warning in particular without having to implement a custom onwarn hook.Would be interesting to hear thoughts further, will leave this up to track any complaints of circular reference noise.
The text was updated successfully, but these errors were encountered: