-
Notifications
You must be signed in to change notification settings - Fork 22
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
feature(ruleset): add recommended, extended rulesets #3
Conversation
mohanraj-r
commented
Mar 13, 2020
•
edited
Loading
edited
- Add recommended, extended preset rules
- Refactor to use Project References · TypeScript
- Refactor to switch to babel jest from ts-jest (Fixes Migrate from ts-jest to babel typescript transformer #4)
- Add spell checker, typescript doc plugin
add single quote pref to editor config
moved comments for enabled options from inline to their own line because prettier strips the whitespace in inline comments
this was resulting in errors from the typescript eslint plugin
|
||
describe('@sa11y/rules sanity checks with axe', () => { | ||
// Rules that have been excluded from running due to being deprecated by axe | ||
// or due to their experimental nature |
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.
What is the source of truth for this list? Or asked another way, how do we know when this list is stale and we need need to update it?
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 have an internal doc that we maintain with the product accessibility team (@cordeliadillon & Jesse )
Currently making sure the rules here are in sync with the doc is a manual process.
I have been also wondering about how this could be automated to make sure it is updated.
Versioning the doc itself and maintaining a changelog in the doc along with current deployment status might help.
Or to ease maintenance and sync overhead could we make this repo the single source of truth and deprecate the doc @cordeliadillon ?
If there is a better process please let me know.
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.
Since @cordeliadillon might be busy with the feature freeze support think it might be better to open an issue to deal with this a little later without blocking this PR ?
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.
I don't consider this blocking for the PR, just want to make sure we have a plan going forward :). Issue is fine for now.
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.
Thanks Trevor. Opened #5
packages/rules/lib/index.ts
Outdated
function rules() { | ||
// TODO | ||
} | ||
export default extended; |
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.
How do users use just the "recommended" ruleset rather than the extended?
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.
The recommended ruleset is also exported. Shouldn't that make it available if users want to import it. Sorry if I am missing something.
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.
The assertAccessible and Jest APIs would default to extended and have an option to override to recommended. Guess it will become clear when those packages are added?
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.
Yeah I think that makes sense to have it default to one with the option for the other.
Also, you didn't update the logic in this PR specifically but I don't think the way the |
@trevor-bliss Yes you are right, I wanted to check with you on this. If there are examples of monorepo Typescript projects that publish to npm in salesforce, please let me know - I will take a look. |
@mohanraj-r It's relatively complex but the LWC monorepo is an example of multiple subpackages that use typescript and lerna. https://github.com/salesforce/lwc/blob/master/package.json#L20 I think the main thing for this project is the |
to follow more widespread naming practices
add a tsconfig specific to rules, move dist to rules,
Thanks @trevor-bliss Btw, reg the package name
|
Yes, I think something like preset-rules or axe-config would be better than just "rules". When I see rules I assume there will be custom rules in here. I wouldn't bother making a |
to follow common naming conventions
to prevent double compilation - build time reduced in half
Renamed package to
Makes sense - was thinking the same 👍 Also switched from ts-jest to babel jest. |
@cordeliadillon I have merged the PR which adds the recommended, extended rules. When you get to it if you have any comments on this PR please let me know, I will take care of it in the next PR. Also when you get some time we can discuss about the source of truth for rulesets (#5) - not urgent but important. |