-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Eslint: Add rule to prohibit unsafe APIs #27301
Conversation
Size Change: +42 B (0%) Total Size: 1.2 MB
ℹ️ View Unchanged
|
Example output from Gutenberg (npm run lint-js) without the rule disabled: lint results
|
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.
This is really cool and the proposed configuration is excellent:
- disabled in Gutenberg
- errors for external usage of
@wordpress/eslint-plugin
It will give feedback whenever someone tries to use those experimental APIs which otherwise could be misunderstood.
One note, it would be good to link to some documentation when showing an error.
Based on improvements in WordPress/gutenberg#27301
Agreed… do you think a link to the rule's documentation, or to the documentation on experimental and unstable features? |
How about this one: https://developer.wordpress.org/block-editor/contributors/develop/coding-guidelines/#experimental-and-unstable-apis? |
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.
Now that this rule isn't in use, according to what we discussed in https://github.com/WordPress/gutenberg/pull/27301/files#r531074490, we can merge it and start playing with it in external projects.
Limitations: This is limited to imported names from @wordpress/* modules. This covers some of the features, but will not prevent usage of experimental or unstable APIs that do not appear as imported names. For example, this would not cover component properties like <MyComponent __experimentalProp={ true } />.
The usage in JSX would be quite a good candidate to enhance this rule in the future. Another use case I can think of is select
or dispatch
calls (and their counterparts) that use selectors and actions. Although the latter is quite challenging to process.
Yes, it's more difficult. I wonder |
Description
Add a rule
@wordpress/no-unsafe-wp-apis
to prohibit usage of__unsafe
and__experimental
exported names from@wordpress/*
packages. Usage of these features is discouraged.See the included documentation.
Limitations: This is limited to imported names from
@wordpress/*
modules. This covers some of the features, but will not prevent usage of experimental or unstable APIs that do not appear as imported names. For example, this would not cover component properties like<MyComponent __experimentalProp={ true } />
.Todo:
How has this been tested?
Includes tests.
Types of changes
New feature: Add
@wordpress/no-unsafe-wp-apis
to discourage use of experimental and unstable features.Checklist: