Skip to content
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

Merged
merged 48 commits into from
Mar 24, 2020

Conversation

mohanraj-r
Copy link
Contributor

@mohanraj-r mohanraj-r commented Mar 13, 2020

Mohan Raj Rajamanickam added 29 commits March 12, 2020 14:49
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
@mohanraj-r mohanraj-r requested a review from a team March 20, 2020 22:52
@mohanraj-r mohanraj-r marked this pull request as ready for review March 20, 2020 22:52

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

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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 ?

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks Trevor. Opened #5

function rules() {
// TODO
}
export default extended;

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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?

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.

@trevor-bliss
Copy link

Also, you didn't update the logic in this PR specifically but I don't think the way the dist folder is generated is correct. I'm not sure exactly how you'll end up delivering/publishing the packages yet but that should be revisited in a future PR.

@mohanraj-r
Copy link
Contributor Author

Also, you didn't update the logic in this PR specifically but I don't think the way the dist folder is generated is correct. I'm not sure exactly how you'll end up delivering/publishing the packages yet but that should be revisited in a future PR.

@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.

@trevor-bliss
Copy link

trevor-bliss commented Mar 23, 2020

@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
https://github.com/salesforce/lwc/blob/master/packages/%40lwc/engine/package.json#L14

I think the main thing for this project is the dist should be generated per project (packages/rules/dist) and the package.json in the rules project should update it's files entry to point to the local dist. It also doesn't make sense to publish the tests here in the dist.

Mohan Raj Rajamanickam added 3 commits March 23, 2020 16:34
@mohanraj-r
Copy link
Contributor Author

@mohanraj-r It's relatively complex but the LWC monorepo is an example of multiple subpackages that use typescript and lerna.
...
I think the main thing for this project is the dist should be generated per project (packages/rules/dist) and the package.json in the rules project should update it's files entry to point to the local dist. It also doesn't make sense to publish the tests here in the dist.

Thanks @trevor-bliss
Looked at a bunch of typescript lerna projects ..
Added a typescript project ref to the root tsconfig and added a tsconfig specific to rules package which puts the dist under the package dir.
Looks like there is currently no way to reuse the outDir and some related settings in tsconfig without duplicating them for each package as they are relative to the dir containing the tsconfig.
Also added exclusion for tests.

Btw, reg the package name

  • would preset-rules be better?
  • would putting published packages under packages/@sa11y/ be better to differentiate them from internal/unpublished packages (of which I don't see the need for now)

@trevor-bliss
Copy link

Btw, reg the package name

  • would preset-rules be better?
  • would putting published packages under packages/@sa11y/ be better to differentiate them from internal/unpublished packages (of which I don't see the need for now)

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 @sally folder until there are private unpublished packages in this repo. That's something you can change later if you need to.

@mohanraj-r
Copy link
Contributor Author

@trevor-bliss

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.

Renamed package to preset-rules

I wouldn't bother making a @sally folder until there are private unpublished packages in this repo. That's something you can change later if you need to.

Makes sense - was thinking the same 👍

Also switched from ts-jest to babel jest.

@mohanraj-r mohanraj-r merged commit 3ff2af7 into master Mar 24, 2020
@mohanraj-r mohanraj-r deleted the feat/add_package_rulesets branch March 24, 2020 21:37
@mohanraj-r
Copy link
Contributor Author

@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.

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.

Migrate from ts-jest to babel typescript transformer
2 participants