-
Notifications
You must be signed in to change notification settings - Fork 8
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
Run dartanalyzer directly #4
Comments
The purpose of this action is to reflect the score that your package would have once it's published, thus I don't think I'll add a way to use the Why do you want this to be included in this action, as you can run |
pub.dev currently is not using the latest version of
I think, in practice, authors want to know the contributions are aligned to the package's own rules in addition to what pana suggests. In case a package has a conflicting rule with what pana suggets, package authors may take action to align their rules to pana or purposely break them. But at least this action would highlight the discrepancies the package rules have. If a package has it's own On a practical note, you've got everything ready to publish annotations, so addition of direct usage of I think the ability to run |
So to be clear, you want this action:
- to alert you when the package's own rules conflict with `pedantic`,
- or to dismiss linting annotations that don't conform to these rules?
|
To boil it down:
|
Here's how I would implement this: I would make it show a warning for each linting rule used by pana that is not in the
I don't think I will do that because it seems to me that this is not the purpose of this action.
I could eventually do that. |
Btw, are you aware that you can filter annotations shown by their level? But I guess you just want to hide those related to linting? |
That's unfortunate. I hoped I could use this action to improve my process. 😞 At the current state this action is quite useless. Take a look at this: https://github.com/gql-dart/gql/pull/44/checks?check_run_id=434318706 Anyway, thanks for your great work! I guess I'll be forking it to add this feature to my workflow. |
@klavs If I said that this is not the purpose of this action, it's because you can already launch the dartanalyzer by yourself in your workflow (as you did as I saw), so this would be redundant. About your package and the difference between the health score on the pub site and the one given by this action, after a little investigation I think that this is due to a bug of the pana package. I'm not entirely sure of that but I created an issue: dart-lang/pana#614. |
No problem.
Nope, it's related to this:
And the general issue has been discussed here where I suggested to take |
That's right! I knew I'd read something like that (I've even subscribed to this thread...). However, when I tried to run pana on your repository on Windows, scores were both at 100. So I still think that my issue could be relevant. |
@klavs On a side note, I noticed that your workflow file has a lot of similar jobs that differ only on the package name. This is just a suggestion, but in case you don't already know that, there is a parameter called |
Hey @klavs, I made a little update today that allows to use your own analysis options file. Tell me what you think about it! |
Well I drop it for now. For two reasons:
|
I'm gonna close this issue, because I think that this action could approximately do what you want. |
Background
Pana is currently ignoring package's own
analysis_options.yaml
, instead usingpedantic
.pedantic:1.9.0
has introduced some controversial rules.Proposal
In addition to running pana, which gives a good feel of how the package will look if published, also run
dartanalyzer
to give feedback on conformance to package's own rules even if a package not supposed to be published.The text was updated successfully, but these errors were encountered: