React: Include canary tests of community packages as part of the release process

[ljharb]

(cc @gaearon, from https://github.com/yannickcr/eslint-plugin-react/issues/1258#issuecomment-311211399)

In general, there's lots of little utilities that are helpful to have as standalone packages. One of them is https://unpkg.com/[email protected]/build/helpers/getComponentName.js, for example.

It'd be ideal for the React team to maintain this package - primarily, so that it would be guaranteed to either not break when a new React version is released, or be updated to work with the upcoming version prior to release.

In the interests of the React team not signing up to maintain all the package requests that might come in, would it be possible to make "part of the release process" be "ensure compatible versions of community packages exist"? I'd be happy to create the above package, for example, and I know the community would love a guarantee that enzyme would always work with any official React version release, prior to the release.

[gaearon]

What other utilities do you have in mind?

[ljharb]

React.isValidElement, the lists of HTML element names, lists of event names - there's a number of things people have had to either depend on all of react for, or copy/paste out of react's codebases, to be able to access.

[gaearon]

the lists of HTML element names

Which ones? React doesn't have a whitelist for tag names anymore.

lists of event names

How do you use these? For linting?

[ljharb]

Here's a few potential examples that I can recall:

• https://github.com/airbnb/enzyme/blob/master/src/Utils.js#L380-L422
• https://github.com/airbnb/prop-types/blob/f76a58c2d8f94292c5843325c3b4d95c87a51726/src/object.js#L10-L14
• https://github.com/evcohen/jsx-ast-utils/blob/master/src/eventHandlers.js
• React.isValidElement in airbnb-prop-types, in that if it depended on that, it would no longer need to depend on any particular version of React; just on a range of the isValidElement package which is far less likely to change across major React versions.
• https://github.com/yannickcr/eslint-plugin-react/blob/master/lib/rules/no-unknown-property.js#L17-L126

Regardless, interrogating each use case as it comes up isn't particularly scalable or productive; the fact remains that people have found use cases that would be made much easier and more robust against changes in React if they were exposed modular packages (that React either depended on directly, or, ran tests against as described above, and as node.js does, to prevent ecosystem breakage).

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.

[ljharb]

Bump.

[stale[bot]]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[ljharb]

bump

[stale[bot]]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[ljharb]

bump

[rickhanlonii]

Since this issue was filed, React started publishing automated next releases with guidance for how to do integration testing between React and other projects.

With this process, package maintainers can now automate checks for breaking changes in React, and make sure that compatible versions of community packages exist without the React team signing up to maintain all the package requests that might come in.

[ljharb]

That's helpful, for sure, but the ask was specifically for the React team to sign up to do this testing prior to publishing a release, particularly because the React team is best positioned to either fix the upcoming React release, or to know in what way the broken library would need to adapt.

The additional request in this thread was for the individual pieces of React - the canonical implementations - to be published separately so that the ecosystem can use them without fear of divergence.

[stale[bot]]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[ljharb]

bump

[rickhanlonii]

The ask was specifically for the React team to sign up to do this testing prior to publishing a release

We provide a way to do this testing before a release. The process is for libraries to run their automated tests (which they are an expert in writing and maintaining) against the next branch of React. We publish next ahead of stable releases, so if there is an issue then the maintainer can flag it before the stable release.

Going to close this because the process we have achieves the same goals without needing React to maintain a hard dependency community packages.

[ljharb]

@rickhanlonii doing that would mean tests might magically start failing despite the project having no changes, which would cause a lot of disruption (and is the whole point of having lockfiles). How do you suggest projects do this without having PRs suddenly start failing due to no fault of the PR author, or the project's default branch starting to fail due to no fault of the project?

[rickhanlonii]

From the linked doc:

• Set up a cron job using your preferred continuous integration platform. Cron jobs are supported by both CircleCI and Travis CI.

• In the cron job, update your React packages to the most recent React release in the Next channel, using next tag on npm.

This means you will be notified asynchronously (not land blocking) of any upstream issues and can look into the cause. If it's because React broke a publicly documented API, then you can file an issue for us to look into.

[eps1lon]

https://reactjs.org/docs/release-channels.html#next-channel has some more info with an example from nextjs

Approach we're using with Material-UI:

• Run test suite on a daily schedule (Azure and GitHub actions support them as well) with
  
  
  
  • react (and friends e.g. scheduler, react-is etc.) with next
  
  
  • A patch applied that adjust tests (e.g. changed warnings, double-render logging in StrictMode etc) or enables features (e.g. the new JSX transform)
    
    The patch is relevant so that we can incrementally fix problems and get notified if a new issue arises.
  
  

Relevant files:

• CircleCI config
• Azure pipelines config
• scripts/use-react-dist-tag

This occasionally breaks if the patch is outdated. It might be better to branch via runtime instead of via git but you have to figure this out for yourself what works best for oyu. With our approach we can have a dedicated person for react@next compat and the rest of the collaborators doesn't have to bother with react@next.

Worked great for us (async cleanup considerations, changes in focus events) and benefited react (2 bugs caught prior to rc.0).

This is seems to work fine if a new release is cut every other week. But so far the team has been responsive if you asked for a new release if it was lagging behind a few months. I guess the next step is release automation with NPM's automation tokens.