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

Define types for plugin events #6322

Merged
merged 22 commits into from Feb 5, 2020
Merged

Conversation

chrisbreiding
Copy link
Contributor

@chrisbreiding chrisbreiding commented Feb 4, 2020

User facing changelog

Define TypeScript types for plugin events

Additional details

This allows all the benefits of TypeScript for plugin events (type-checking, auto-completion, etc).

Documentation PR: cypress-io/cypress-documentation#2466

How has the user experience changed?

I don't know how users can utilize this. I don't think it will work by default, so someone more knowledgeable with TypeScript will need to help answer that.

PR Tasks

  • Have tests been added/updated?
  • Has the original issue been tagged with a release in ZenHub?
  • Has a PR for user-facing changes been opened in cypress-documentation?
  • Have API changes been updated in the type definitions?
  • N/A Have new configuration options been added to the cypress.schema.json?

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Feb 4, 2020

Thanks for the contribution! Below are some guidelines Cypress uses when doing PR reviews.

  • Please write [WIP] in the title of your Pull Request if your PR is not ready for review - someone will review your PR as soon as the [WIP] is removed.
  • Please familiarize yourself with the PR Review Checklist and feel free to make updates on your PR based on these guidelines.

PR Review Checklist

If any of the following requirements can't be met, leave a comment in the review selecting 'Request changes', otherwise 'Approve'.

User Experience

  • The feature/bugfix is self-documenting from within the product.
  • The change provides the end user with a way to fix their problem (no dead ends).

Functionality

  • The code works and performs its intended function with the correct logic.
  • Performance has been factored in (for example, the code cleans up after itself to not cause memory leaks).
  • The code guards against edge cases and invalid input and has tests to cover it.

Maintainability

  • The code is readable (too many nested 'if's are a bad sign).
  • Names used for variables, methods, etc, clearly describe their function.
  • The code is easy to understood and there are relevant comments explaining.
  • New algorithms are documented in the code with link(s) to external docs (flowcharts, w3c, chrome, firefox).
  • There are comments containing link(s) to the addressed issue (in tests and code).

Quality

  • The change does not reimplement code.
  • There's not a module from the ecosystem that should be used instead.
  • There is no redundant or duplicate code.
  • There are no irrelevant comments left in the code.
  • Tests are testing the code’s intended functionality in the best way possible.

Internal

  • The original issue has been tagged with a release in ZenHub.

@chrisbreiding chrisbreiding changed the base branch from develop to v4.0-release February 4, 2020 20:50
@chrisbreiding
Copy link
Contributor Author

@bahmutov How can we add tests for this like for Cypress tests? Is this even the right place to put this, next to the other types? They're 2 different environments...

cli/types/index.d.ts Outdated Show resolved Hide resolved
@cypress
Copy link

cypress bot commented Feb 4, 2020



Test summary

3634 0 46 0


Run details

Project cypress
Status Passed
Commit 3d44a39
Started Feb 5, 2020 6:48 PM
Ended Feb 5, 2020 6:53 PM
Duration 04:58 💡
OS Linux Debian - 9.11
Browser Multiple

View run in Cypress Dashboard ➡️


This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

@chrisbreiding chrisbreiding changed the title [WIP] Define types for plugin events Define types for plugin events Feb 4, 2020
@jennifer-shehane
Copy link
Member

jennifer-shehane commented Feb 5, 2020

I bumped the kitchensink dep with the released JSDoc changes.

I also added this change to the 4.0 changelog, let me know if there's any other documentation required for this.

@chrisbreiding
Copy link
Contributor Author

@jennifer-shehane We should probably add this to the TypeScript doc, right? An example for how to utilize it is now in the kitchen sink repo

@jennifer-shehane
Copy link
Member

@chrisbreiding Yes, I'm not really familiar with what these changes mean for users, so open an issue/PR for docs.

@brian-mann
Copy link
Member

@bahmutov and @flotwig and @bkucera can ya'll comment here helping answer Chris's questions?

@chrisbreiding
Copy link
Contributor Author

@brian-mann My questions were answered. This is good to go now.

@brian-mann brian-mann merged commit 4b4842e into v4.0-release Feb 5, 2020
@chrisbreiding chrisbreiding deleted the issue-6321-plugin-types branch April 5, 2022 18:29
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.

Add types for plugin events
4 participants