-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
feat(boundaries): add ignore directive #9938
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
d69124b
to
8d46bba
Compare
fn is_ignored_import(comments: &SingleThreadedComments, span: Span) -> bool { | ||
if let Some(import_comments) = comments.get_leading(span.lo()) { | ||
for comment in import_comments { | ||
if comment.text.trim() == "@boundaries-ignore" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about branding the ignore, and requiring a reason?
// @turbo-boundaries-ignore -- we're yolorepo-ing
A little eslinty, but I think requiring reasons here would be very helpful for maintainers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. Do you think we should do @turbo-boundaries-ignore
? I kinda like just @boundaries-ignore
// If the import is prefixed with `@boundaries-ignore`, we ignore it, but print | ||
// a warning | ||
if Self::is_ignored_import(&comments, *span) { | ||
if warning_count <= MAX_IGNORE_WARNINGS { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add another case here that outputs the total count of warnings that exceeded the max?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think separating out display logic in check_package
will be beneficial in the future. Also allows us to write unit tests checking if warnings were created.
for (import, span, import_type) in finder.imports() { | ||
// If the import is prefixed with `@boundaries-ignore`, we ignore it, but print | ||
// a warning | ||
if Self::is_ignored_import(&comments, *span) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we avoid having the display logic inside of check_package
and instead have check_package
return diagnostics and then have a some sort of "reporter" decide on what to do about each diagnostic? I think we'll want to eventually offer a way to disallow this escape hatch (or on CI display all warnings). Should also make it easier to write unit tests for this codepath.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed it to store the warnings. We could keep the diagnostics and annotate them as disabled, but I think this works fine for now. If we want to disallow the ignore annotation, we can also just make the is_ignored_import
check return false
@@ -5,3 +5,20 @@ import { Ship } from "ship"; | |||
import { Ship } from "@types/ship"; | |||
// Import package that is not specified | |||
import { walkThePlank } from "module-package"; | |||
|
|||
// Import from a package that is not specified, but we have `@boundaries-ignore` on it | |||
// @boundaries-ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this have produced a change in a test fixture where a warning is printed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't snapshot warnings since they go to stderr. I'm not sure if we should, since that could be pretty brittle (and also makes debugging tests slightly annoying)
8d46bba
to
284dedf
Compare
### Description Add ability to ignore imports for boundaries by commenting `// @boundaries-ignore` ### Testing Instructions Added tests to boundaries fixture
Description
Add ability to ignore imports for boundaries by commenting
// @boundaries-ignore
Testing Instructions
Added tests to boundaries fixture