feat(no-uninstalled-addons): add uninstalled plugin rule

[andrelas1]

Issue: #95

What Changed

Checklist

Check the ones applicable to your change:

• Ran yarn update-all
• Tests are updated
• Documentation is updated

Change Type

Indicate the type of change your pull request is:

• maintenance
• documentation
• patch
• minor
• major

[andrelas1]

Solves #95

[andrelas1]

The only issue I still see here is that ESLint won't lint any file inside dot-folders by default and the user of this plugin will have to write something like this to lint the main.js file:

// .eslintignore file
# Allowlist 'test.js' in the '.build' folder
# But do not allow anything else in the '.build' folder to be linted
!.storybook

Not ideal but not sure if we can make this rule sort of override the default behaviour of ESLint.

[yannbf]

This is so nice @andrelas1 thank you so much for your contribution!!

I added a few comments if you don't mind

[yannbf]

The only issue I still see here is that ESLint won't lint any file inside dot-folders by default and the user of this plugin will have to write something like this to lint the main.js file:

// .eslintignore file
# Allowlist 'test.js' in the '.build' folder
# But do not allow anything else in the '.build' folder to be linted
!.storybook

Not ideal but not sure if we can make this rule sort of override the default behaviour of ESLint.

This is interesting. Maybe we do want to lint the entire storybook folder, so it allows us in the future to add more rules to other files like preview.js, manager.js etc

[yannbf]

This is AMAZING thank you so much @andrelas1 <3

[github-actions]

🚀 PR was released in v0.6.0 🚀

[jdehaan]

This relies too much on package.json being in the exact same folder, which is not always the case. For instance in our projects we tend to put the config files for storybook into its own folder inside config/storybook while the project package.json remains in the top level folder. Is there a chance to provide a configuration for this or extend the code so it drills up through the folders like npm looks like to do?

[yannbf]

Hey @jdehaan thanks for this comment! Would something like this suffice?

{
  "overrides": [
    {
      "files": ["whatever-is-your-config-dir/main.@(js|ts)"],
      "rules": {
        "storybook/no-uninstalled-addons": ["error", { "packageLocation": "./" }],
      }
    }
  ]
}

1 - You are able to set the location of the main.js file which will get the rule applied (currently possible)
2 - You are able to set the location of which the package.json that contains the addons is located at (needs to be implemented)

---

Another possible solution would be to use something like pkgUp to find the closest package.json, which could work in your scenario, but still yield a false-positive result in scenarios where the package.json that was found is not the correct one.

[jdehaan]

Thanks for the quick feedback.

I also think that an explicit option is the safest way to go, these things won't jump up and down at all times and a one time configuration effort is fully ok and preferable to some black magic IMO. For very fancy configuration needs one could even provide an own configuration logic upfront generating pairs of main.js/package.json for bigger monorepos... So yes I would be fully happy with your configuration proposal!

[menelaos]

@yannbf Currently, if package.json is not found, the error is only logged to the console. It should probably be re-thrown or handled in a way that results in a non-zero exit status. At the moment, the linting process will silently pass.

[yannbf]

Hey @jdehaan @menelaos, a new version has been released including this feature! #102

And @menelaos that was intentional. We don't want people's projects to break so this plugin blocks them. The plugin now just acknowledges the issue and provides a link to the docs on how to fix it.

Thank you all!

[jdehaan]

Works like a charm, beside that the new package features a smarter package.json resolution as I did not have to specify it anymore in many cases. Thanks!

[yannbf]

All thanks to @andrelas1 great work!

[menelaos]

@yannbf @andrelas1 Thank you!