How To Pick Cypress Plugins You Can Trust

Recently a Cypress user asked a good question:

One of Cypress's powerful features is its support of plugins and there are many really powerful ones, but it also raises some concerns about risks of relying on additional dependencies. You've got to be confident of a plugins functionality, security and also ensure you're updating to latest. This makes me a bit un-easy. Curious how others have rationalized or dealt with such concerns.

This is a great question. Do you install a lot of 3rd-party plugins in your Cypress projects? Do you only trust Cypress official plugins? Do you write a lot of custom testing code? There are a lot of Cypress plugins out there. I personally use a lot of plugins, here is a portion of package.json from my Mercari US E2E repo:

package.json

{
  "devDependencies": {
    "cypress": "13.12.0",
    "cypress-cdp": "^1.4.0",
    "cypress-data-session": "^2.8.0",
    "cypress-each": "^1.11.0",
    "cypress-file-upload": "^5.0.8",
    "cypress-get-by-label": "^2.5.0",
    "cypress-high-resolution": "^1.0.0",
    "cypress-highlight": "^1.1.0",
    "cypress-if": "^1.12.3",
    "cypress-ld-control": "^1.12.0",
    "cypress-log-to-term": "^1.5.1",
    "cypress-mailosaur": "^2.14.0",
    "cypress-map": "^1.36.2",
    "cypress-network-idle": "^1.14.2",
    "cypress-on-fix": "^1.0.3",
    "cypress-real-events": "^1.12.0",
    "cypress-recurse": "^1.34.0",
    "cypress-set-github-status": "^2.0.4",
    "cypress-slack-notify": "^1.14.0",
    "cypress-testrail-simple": "^3.2.1",
    "cypress-timestamps": "^1.2.3",
  }
}

I often use the excellent cypress-real-events plugin plus cypress-map and cypress-data-session. I wrote before about my My favorite Cypress plugins and My favorite Cypress plugins, part II. Here is how I think about Cypress core and its plugins.

1. Cypress core Test Runner by itself comes with many bells and whistles: assertions, Lodash, Blob, etc. But it is missing lots of things I need. For example, I love reusable chains of query commands, yet Cypress API is still very limited in this regard. A plugin like cypress-map is a 100% must in all my projects, since it fills the gaps in the functionality.
2. Cypress core Test Runner almost never merges in features from the plugins. The only thing they have "merged" is my component testing plugins. This is a huge problem. Things like @bahmutov/cy-grep and cypress-await should be part of the core Test Runner, not a plugin. But the Cypress team does not see it this way, I guess.
3. If you have a choice between bringing a plugin or writing the support code yourself: USE THE PLUGIN. Your development time costs money. What are you doing spending work hours on the things that exist?!

Which brings us to the follow-up question from the same user:

I still have some un-ease of having lots of dependencies and, even if from very reputable dev like yourself, there's some risk. I'd give the example of what if you won the lottery, but I suspect you'd still be supporting your plugins then.

Disclaimer: I don't know what I would do if I won a lottery. My hunch is that I would be doing open-source work plus soccer coaching ⚽️ Here is the thing about open-source: any of my plugins can be forked and worked on in the future. If you need a specific feature and would like me to develop it, please consider sponsoring my GitHub work.

Having said this, here is how I would pick the plugins to include in my work projects:

• is this a necessary plugin, or is there an alternative Cypress core command? Cypress API is large and powerful. Often we don't need any additional commands to upload a file, for example.
• is the plugin open-source with all its tests and build steps available? I would never use a plugin with just its NPM module published, I need to have a GitHub repo in case I would like to fork the plugin
• is the plugin well-tested? Is there a build / test / release workflow? Inspect the tests, do they look reasonable for the plugin's features?
• how many releases does the plugin have? When was the last release? Does it have many open bugs and issues? I would not worry about feature requests though; I often open GitHub issues with ideas for future enhancements, but I might never have time or energy to work on them (yet)
• is the plugin popular? How many GitHub stars and NPM downloads does it have? You can grab this information from https://npmtrends.com/ Here are a couple of my plugins

You can also quickly glance the downloads information from the NPM page for each plugin, for example https://www.npmjs.com/package/cypress-split

• is the plugin used by other projects? The more projects use a plugin, the better. A battle-tested plugin is much better than any custom source code you write in your own single project. You can see how many GitHub public projects depend on the plugin, which is only a part of all projects that might use it.

You can click on the "dependent projects" to see them, here is the list from https://github.com/bahmutov/cypress-split/network/dependents

Finally, if you are using a plugin for your business work and are worried about support and maintenance: sponsor the plugin's developers! For my plugins, you can either sponsor me using GitHub or buy my Cypress courses like the extensive Cypress Plugins course, or even invite me to do in-person or remote training for your team.