Add client library tests and code quality infrastructure

[emdashcodes]

This PR adds test coverage and code quality to the client package. It follows-up on the following two PRs: #60 and #69.

It adds:

• Jest test setup based on wp-scripts
• 95% code coverage for client code
• ESLint & Prettier setup based on wp-scripts
• Contributor documentation
• CI infrastructure

Things are broken down into a few separate commits to make things easier to review. Apologizes again for package-lock.json inflation.

• Add testing & linting infrastructure 8f6352d
• Minor formatting fixes 50722d5
• Client package tests 1ffe05d

Testing

• See that all CI checks pass below

• Locally

# Lint all JavaScript/TypeScript files
npm run lint:js

# Run TypeScript typecheck
npm run typecheck

# Run all JavaScript tests
npm run test:client

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: emdashcodes <[email protected]>
Co-authored-by: gziolo <[email protected]>
Co-authored-by: justlevine <[email protected]>
Co-authored-by: jonathanbossenger <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.78%. Comparing base (75e57b8) to head (5f87e5e).
⚠️ Report is 1 commits behind head on add/client-only-abilities.

Additional details and impacted files

@@                       Coverage Diff                       @@
##             add/client-only-abilities      #70      +/-   ##
===============================================================
+ Coverage                        77.89%   81.78%   +3.88%     
  Complexity                         103      103              
===============================================================
  Files                                9       15       +6     
  Lines                              552      741     +189     
  Branches                             0       75      +75     
===============================================================
+ Hits                               430      606     +176     
- Misses                             122      135      +13     

Flag	Coverage Δ
javascript	93.12% <100.00%> (?)
unit	77.89% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gziolo]

I reviewed this PR and left my feedback to consider.

[gziolo]

executeAbility would be the most considerable difference with the server. This is more high-level feedback, which doesn't have to be immediately addressed, more like a discussion starter.

Would it make sense to mirror that on the server and offer wp_execute_ability?

In the same fashion, could getAbility always return an object that would allow calling:

const ability = await getAbility( 'my/ability' );
const result = await ability.execute( input );

Aside, all tests deal with sync callbacks, but I noticed that some examples documented could be async. We also have server abilities that don't have the callback, but maybe we could provide a general handler there, too.

[emdashcodes]

wp_execute_ability does seem like it could be useful. I need to think about this discussion more but wanted to note that I saw it.

ability.execute feels a little odd to me at initial glance 🤔

[gziolo]

@copilot, what are your thoughts on this thread?

Let's see if it can respond here 😄

[gziolo]

ability.execute feels a little odd to me at initial glance 🤔

Right, it doesn't translate that well into JavaScript code.

[justlevine]

I made the mistake of reviewing #60 before looking at this. Tl;Dr

1. I think we'll all have a much easier time if we treat this like a monorepo, use NPM workspaces and run all the dev/build commands top-level, and more generally follow the patterns used in the Gutenberg repo (whether that's the eventual home of a merged package or not, it's still peer-reviewed prior art that contributors are already familiar with)

2. Either way, not sure I follow the need for two GH workflows. If this tiny public repo really needs some paths filtering, then we can do it with https://github.com/dorny/paths-filter or similar. (Otherwise at least filter packages/* out of test.yml and do all the JS related stuff, including testing in js-lint.yml js-test.yml

[jonathanbossenger]

Commenting only on the documentation updates (which is where my focus has been for this project), it all looks good to me.

[gziolo]

I don't have more feedback for this PR other than a nitpick regarding usage console.warning over warnining from @wordpress/warning. It looks like all my important concerns raised where addressed.

It still needs some testing, which I plan to do tomorrow.

@emdashcodes, I'm not entirely sure how you would like to go about merging the code, but since it isn't targeting trunk I figured out, I approve it in case you would like to combine #69 and #70 together. It still will require testing, so this way I would review changes applied to #69 and test both PR at once.