Source code policy

Add-ons Add-on Support
1

Hi, I am one of the maintainers of React DevTools - React Developer Tools – Get this Extension for 🦊 Firefox (en-GB), which is official browser extension for debugging React applications.

A few last updates were blocked by the review team, because of source code policy violation. This is the quote from the reply that we’ve received after sending an appeal:

As per Mozilla’s add-on policies, only release versions of third-party libraries and/or frameworks may be included with an add-on. According to your documentation (ADD LINK), “canaries” versions are considered pre-releases and therefore do not meet this compliance requirement set by our policies.

Basically, the review team is unhappy that React DevTools is using React from source and not from npm or any other public package repositories.

I think it is worth noting that we’ve already had multiple successful releases, since the adoption of this policy rule. This policy rule is really questionable in regards to developer tooling: if I am developing React, my developer tools for it should support the latest versions of the library.

Another point that is worth noting, I don’t think that React should be treated as third-party code in React DevTools. I believe that the only reason why this is being considered as third-party code is the fact that it is loaded from CI, when review team checks the source code and attempts to reproduce the build? Will this rule still apply if the review team would wait for React to be built locally, while they are creating a build of React DevTools?

Could we please get any comments regarding this policy rule and its interpretation for extensions like React DevTools? We would love to ship our latest release to Firefox users, to make their experience better - [DevTools Bug]: Firefox extension out of date (v6.0.0, 2024-09-26) · Issue #32771 · facebook/react · GitHub.

Thank you.

1 Like
2

There must be some confusion here, React is not third party to React DevTools. We own both, and they ship from the same codebase.

For context, we ship from React source instead of NPM because it allows us to more easily provide support in DevTools for users installing pre-release versions of React in their own apps, and to dogfood stable features in the React Canary inside DevTools itself.

Our versioning policy quoted in the rejection is not an accurate understanding of our policy or the stability of the version of React we use, but if it helps I can just update the version policy.

3

Hey React folks! Could you reply to the rejection email with this question? Our standard procedure is to have policy questions go through the review team in order to keep the relevant team members involved and answers consistent. That said, I’m happy to help make sure you get the information you need to resolve this issue.

1 Like
4

Hey Simeon,

Will do. For this issue - it would be great if the Third-Party Library Usage docs here clarified what counts as Third Party.

For example, if I publish some source code in an extension and additionally extract some of that source code out and publish it in a package to NPM, it’s not clear if that’s considered third-party since I’m the same party publishing the source code to both distribution channels.