support building with npm

[escapewindow]

Currently, both CI and release builds assume we will build the xpi via yarn build. There are at least a couple repos where developers want npm building support (not sure if this is npm build or npm run build ?).

The actual line in question is here. That's super easy to change. We can key that off of XPI_INSTALL_TYPE or another env var. (If another env var, we should add a corresponding xpi-manifest key and surface that as an env var, like we do with XPI_INSTALL_TYPE.

We should:

• verify what npm build support means
• see which repos need it - currently firefox voice + searchengine devtools?
• we can test what the change will do in our staging manifest repo (I need to move this to a shared location.) We need to make sure that we don't leave anyone broken.
  • if we find there are xpis that we will never need to release again, we can mark them active: false to avoid needing to patch them
  • deal with any bustage, which may include patches to a number of source repos
• we probably need corresponding changes to xpi-template for CI, since it shares the same build docker image
• open PRs to the various repos, land them roughly at the same time

[escapewindow]

The complexity here is not in making the xpi-manifest repo change, but in making sure that we don't leave CI or any given supported repo broken in doing so.

[ianb]

In some documentation it is suggested that the existence of yarn.lock implies it's a yarn project, and package-lock.json implies npm. Using that same pattern here would avoid new project configuration.

[escapewindow]

@ianb xpi-manifest doesn't clone every repo when creating its graph, so it doesn't know what files are in the project. Doing so may slow things down.

[escapewindow]

Additional information:

• searchengine-devtools is an npm project, but yarn build works.
• if we solve the package-lock.json issue in firefox voice and switch it back to npm install, similarly yarn build may just work, and we can close this issue.