-
Notifications
You must be signed in to change notification settings - Fork 65
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: Use linters from regular dependencies #276
Conversation
To view this pull requests documentation preview, visit the following URL: Documentation is deployed and generated using docs.page. |
@dickermoshe is attempting to deploy a commit to the Invertase Team on Vercel. A member of the Team first needs to authorize it. |
We'd want a test where a package depends on a lint using There are similar tests in the packages/custom_lint/test folder |
Seems to be a bug in how the workspace pubspec.yaml file is written. |
It may not be your fault. The master CI is failing AFAIK |
@rrousselGit I've written 2 new tests for this PR. And everything passes. Except.. This is not my fault as you stated. Seems that there is some broken code which is already on Logs
Either way, this PR is done and ready for review! |
When do you think you guys will be releasing a new version of custom_lint once this PR is merged? |
I really find this package useful so I decided to spend some time trying to fix this existing bug. I managed to fixed the Dart SDK error in the I'm not sure what this test is trying to do , so I can't help fix it. Just to be clear, this is your bug, not mine. So IMHO, this shouldn't hold up the PR |
Hello! Then, if the CI is passing I'll evaluate whether this can be merged :) |
I thought you forgot about me 😢 I synced with main and tests pass on my end. Lmk what changes you would want |
// Determine if this is a dev_dependency or a dependency. | ||
// Note: Dependencies can't be in both `dependencies` and `dev_dependencies`. | ||
// So these isNonEmpty checks mutually exclusive. | ||
final bool isDevDependency; |
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 should preserve the source of a dependency.
If it's from dependencies, we write it as dependencies. If it is a dev_dependency, we write it as so.
And the constraints should match.
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.
But what if it's in both?
e.g.
.
├── b
│ └── pubspec.yaml # drift_dev in dev_dependencies
├── c
│ └── pubspec.yaml # drift_dev in dependencies
└── a
└── pubspec.yaml # Root Package , depends on "b" and "c"
Project A
depends on package B
and C
.
If drift_dev
is a dev_dependencies
in package B
and a regular dependency
in C
, how should it be written?
I spent a while trying to understand what this code is doing. If my assumptions are wrong please enlighten me
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.
Actually, I think we should always be writing plugins to dependencies:
, not dev_dependencies:
Because plugins use them directly rather than through command. If the linter was running against its own source, we'd probably see a warning that plugins should be in "dependencies" instead of dev_dependencies.
It works regardless because Dart sometimes doesn't care. But the current code is probably not right.
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 want to preserve dependency_overrides though, those shouldn't change)
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.
Because plugins use them directly rather than through command. If the linter was running against its own source, we'd probably see a warning that plugins should be in "dependencies" instead of dev_dependencies.
Good point.
-
I've updated the code to combine
dev_dependencies
anddependencies
and to always write them as regulardependencies
in the generated pubspec. -
I've updated the tests and wrote a new test for dealing with conflicting dev and regular dependencies.
-
I've also refactored some of the code to make it match the original as most as possible.
Let me know if there is anything else I should do
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.
@rrousselGit
a-hem
You've got lost of packages, I know, whenever you get a chance...
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.
Sorry, let me have another look.
fix: all child dependencies are combined
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.
Assuming the CI passes, it's looking good!
As of now custom_lint doesn't look for linters installed as regular dependencies. This would change that.
Semi-Fix for broken
CustomLintWorkspace resolvePluginHost runs offline if possible
test too#275
@rrousselGit What sort of tests should be written for this (if any)