Skip to content

Bug 2053531 - Add nimbus-fml lint - #7563

Open
travis79 wants to merge 1 commit into
mainfrom
Bug2053531
Open

Bug 2053531 - Add nimbus-fml lint#7563
travis79 wants to merge 1 commit into
mainfrom
Bug2053531

Conversation

@travis79

Copy link
Copy Markdown
Member

Adds a lint command covering feature metadata, descriptions, naming and feature design, and a no-lint field to silence lints per feature or per file. validate no longer reports feature metadata warnings; that's the lint command's job now.

Pull Request checklist

  • Breaking changes: This PR follows our breaking change policy
    • This PR follows the breaking change policy:
      • This PR has no breaking API changes, or
      • There are corresponding PRs for our consumer applications that resolve the breaking changes and have been approved
  • Quality: This PR builds and tests run cleanly
    • Note:
      • For changes that need extra cross-platform testing, consider adding [ci full] to the PR title.
      • If this pull request includes a breaking change, consider cutting a new release after merging.
  • Tests: This PR includes thorough tests or an explanation of why it does not
  • Changelog: This PR includes a changelog entry in CHANGELOG.md or an explanation of why it does not need one
    • Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
  • Dependencies: This PR follows our dependency management guidelines
    • Any new dependencies are accompanied by a summary of the due diligence applied in selecting them.

Adds a lint command covering feature metadata, descriptions, naming and
feature design, and a `no-lint` field to silence lints per feature or per
file. `validate` no longer reports feature metadata warnings; that's the
lint command's job now.
Comment on lines +341 to +345
let mut raw = Vec::new();
metadata::check_feature(feature, &mut raw);
documentation::check_feature(feature, &mut raw);
naming::check_feature(feature, &mut raw);
design::check_feature(feature, fm, &mut raw);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding these feels like something that could get missed when adding new linting files. Could it be at all viable to instead have the methods be on a trait? Then have the trait get impl'd on structs for each lint type, and have each section iterate through the types and call the appropriate methods?

@freshstrangemusic freshstrangemusic left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with charlie about using a trait for lints and then we can have a Vec<Box<&dyn Linter>> or smth and call the lints from each member.

Comment on lines +238 to +242
let mut subject: Option<(&Option<String>, &String)> = None;

for finding in &report.findings {
let this = (&finding.module, &finding.subject);
if subject != Some(this) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're overloading subject here to be both a (module, subject) and just a finding.subject. Consider renaming subject for clarity.

})
.map_err(|e| {
CliError(format!(
"{e}\nA manifest has to be valid before it can be linted; run `nimbus-fml validate` for the details"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"{e}\nA manifest has to be valid before it can be linted; run `nimbus-fml validate` for the details"
"{e}\nA manifest has to be valid before it can be linted; run `nimbus-fml validate` for details"

pub struct Finding {
pub lint: &'static str,
pub level: LintLevel,
/// Set when the finding came from an imported manifest.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/when/if

Comment thread CHANGELOG.md

- A new API has been added to get the list of enrolled experiments and rollouts without instantiating a NimbusClient: `get_active_enrollments()`. ([#7560](https://github.com/mozilla/application-services/pull/7560))

### Nimbus FML

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These can just be grouped under nimbus.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants