react/scripts/release/utils.js

296 lines
9.4 KiB
JavaScript
Raw Permalink Normal View History

'use strict';
const {exec} = require('child-process-promise');
const {createPatch} = require('diff');
const {hashElement} = require('folder-hash');
const {existsSync, readFileSync, writeFileSync} = require('fs');
const {readJson, writeJson} = require('fs-extra');
const fetch = require('node-fetch');
const logUpdate = require('log-update');
const {join} = require('path');
const createLogger = require('progress-estimator');
const prompt = require('prompt-promise');
const theme = require('./theme');
const {stablePackages, experimentalPackages} = require('../../ReactVersions');
// https://www.npmjs.com/package/progress-estimator#configuration
const logger = createLogger({
storagePath: join(__dirname, '.progress-estimator'),
});
const addDefaultParamValue = (optionalShortName, longName, defaultValue) => {
let found = false;
for (let i = 0; i < process.argv.length; i++) {
const current = process.argv[i];
if (current === optionalShortName || current.startsWith(`${longName}=`)) {
found = true;
break;
}
}
if (!found) {
process.argv.push(`${longName}=${defaultValue}`);
}
};
const confirm = async message => {
const confirmation = await prompt(theme`\n{caution ${message}} (y/N) `);
prompt.done();
if (confirmation !== 'y' && confirmation !== 'Y') {
console.log(theme`\n{caution Release cancelled.}`);
process.exit(0);
}
};
const execRead = async (command, options) => {
const {stdout} = await exec(command, options);
return stdout.trim();
};
const extractCommitFromVersionNumber = version => {
// Support stable version format e.g. "0.0.0-0e526bcec-20210202"
// and experimental version format e.g. "0.0.0-experimental-0e526bcec-20210202"
const match = version.match(/0\.0\.0\-([a-z]+\-){0,1}([^-]+).+/);
if (match === null) {
throw Error(`Could not extra commit from version "${version}"`);
}
return match[2];
};
const getArtifactsList = async buildID => {
const {CIRCLE_CI_API_TOKEN} = process.env;
if (CIRCLE_CI_API_TOKEN == null) {
throw new Error(
`Expected a CircleCI token to download artifacts, got ${CIRCLE_CI_API_TOKEN}`
);
}
Update sizebot to new workflow (#20719) * build-combined: Fix bundle sizes path * Output COMMIT_SHA in build directory Alternative to parsing an arbitrary package's version number, or its `build-info.json`. * Remove CircleCI environment variable requirement I think this only reason we needed this was to support passing any job id to `--build`, instead of requiring the `process_artifacts` job. And to do that you needed to use the workflows API endpoint, which requires an API token. But now that the `--commit` argument exists and automatically finds the correct job id, we can just use that. * Add CI job that gets base artifacts Uses download-experimental script and places the base artifacts into a top-level folder. * Migrate sizebot to combined workflow Replaces the two separate sizebot jobs (one for each channel, stable and experimental) with a single combined job that outputs size information for all bundles in a single GitHub comment. I didn't attempt to simplify the output at all, but we should. I think what I would do is remove our custom Rollup sizes plugin, and read the sizes from the filesystem instead. We would lose some information about the build configuration used to generate each artifact, but that can be inferred from the filepath. For example, the filepath `fb-www/ReactDOM-dev.classic.js` already tells us everything we need to know about the artifact. Leaving this for a follow up. * Move GitHub status check inside retry loop The download script will poll the CircleCI endpoint until the build job is complete; it should also poll the GitHub status endpoint if the build job hasn't been spawned yet. * Only run get_base_build on main branch
2021-02-04 00:29:51 +08:00
const jobArtifactsURL = `https://circleci.com/api/v1.1/project/github/facebook/react/${buildID}/artifacts`;
const jobArtifacts = await fetch(jobArtifactsURL, {
headers: {
'Circle-Token': CIRCLE_CI_API_TOKEN,
},
});
return jobArtifacts.json();
};
const getBuildInfo = async () => {
const cwd = join(__dirname, '..', '..');
Set up experimental builds (#17071) * Don't bother including `unstable_` in error The method names don't get stripped out of the production bundles because they are passed as arguments to the error decoder. Let's just always use the unprefixed APIs in the messages. * Set up experimental builds The experimental builds are packaged exactly like builds in the stable release channel: same file structure, entry points, and npm package names. The goal is to match what will eventually be released in stable as closely as possible, but with additional features turned on. Versioning and Releasing ------------------------ The experimental builds will be published to the same registry and package names as the stable ones. However, they will be versioned using a separate scheme. Instead of semver versions, experimental releases will receive arbitrary version strings based on their content hashes. The motivation is to thwart attempts to use a version range to match against future experimental releases. The only way to install or depend on an experimental release is to refer to the specific version number. Building -------- I did not use the existing feature flag infra to configure the experimental builds. The reason is because feature flags are designed to configure a single package. They're not designed to generate multiple forks of the same package; for each set of feature flags, you must create a separate package configuration. Instead, I've added a new build dimension called the **release channel**. By default, builds use the **stable** channel. There's also an **experimental** release channel. We have the option to add more in the future. There are now two dimensions per artifact: build type (production, development, or profiling), and release channel (stable or experimental). These are separate dimensions because they are combinatorial: there are stable and experimental production builds, stable and experimental developmenet builds, and so on. You can add something to an experimental build by gating on `__EXPERIMENTAL__`, similar to how we use `__DEV__`. Anything inside these branches will be excluded from the stable builds. This gives us a low effort way to add experimental behavior in any package without setting up feature flags or configuring a new package.
2019-10-15 01:46:42 +08:00
const isExperimental = process.env.RELEASE_CHANNEL === 'experimental';
const branch = await execRead('git branch | grep \\* | cut -d " " -f2', {
cwd,
});
const commit = await execRead('git show -s --no-show-signature --format=%h', {
cwd,
});
const checksum = await getChecksumForCurrentRevision(cwd);
const dateString = await getDateStringForCommit(commit);
Set up experimental builds (#17071) * Don't bother including `unstable_` in error The method names don't get stripped out of the production bundles because they are passed as arguments to the error decoder. Let's just always use the unprefixed APIs in the messages. * Set up experimental builds The experimental builds are packaged exactly like builds in the stable release channel: same file structure, entry points, and npm package names. The goal is to match what will eventually be released in stable as closely as possible, but with additional features turned on. Versioning and Releasing ------------------------ The experimental builds will be published to the same registry and package names as the stable ones. However, they will be versioned using a separate scheme. Instead of semver versions, experimental releases will receive arbitrary version strings based on their content hashes. The motivation is to thwart attempts to use a version range to match against future experimental releases. The only way to install or depend on an experimental release is to refer to the specific version number. Building -------- I did not use the existing feature flag infra to configure the experimental builds. The reason is because feature flags are designed to configure a single package. They're not designed to generate multiple forks of the same package; for each set of feature flags, you must create a separate package configuration. Instead, I've added a new build dimension called the **release channel**. By default, builds use the **stable** channel. There's also an **experimental** release channel. We have the option to add more in the future. There are now two dimensions per artifact: build type (production, development, or profiling), and release channel (stable or experimental). These are separate dimensions because they are combinatorial: there are stable and experimental production builds, stable and experimental developmenet builds, and so on. You can add something to an experimental build by gating on `__EXPERIMENTAL__`, similar to how we use `__DEV__`. Anything inside these branches will be excluded from the stable builds. This gives us a low effort way to add experimental behavior in any package without setting up feature flags or configuring a new package.
2019-10-15 01:46:42 +08:00
const version = isExperimental
? `0.0.0-experimental-${commit}-${dateString}`
: `0.0.0-${commit}-${dateString}`;
// Only available for Circle CI builds.
// https://circleci.com/docs/2.0/env-vars/
const buildNumber = process.env.CIRCLE_BUILD_NUM;
// React version is stored explicitly, separately for DevTools support.
// See updateVersionsForNext() below for more info.
const packageJSON = await readJson(
join(cwd, 'packages', 'react', 'package.json')
);
Set up experimental builds (#17071) * Don't bother including `unstable_` in error The method names don't get stripped out of the production bundles because they are passed as arguments to the error decoder. Let's just always use the unprefixed APIs in the messages. * Set up experimental builds The experimental builds are packaged exactly like builds in the stable release channel: same file structure, entry points, and npm package names. The goal is to match what will eventually be released in stable as closely as possible, but with additional features turned on. Versioning and Releasing ------------------------ The experimental builds will be published to the same registry and package names as the stable ones. However, they will be versioned using a separate scheme. Instead of semver versions, experimental releases will receive arbitrary version strings based on their content hashes. The motivation is to thwart attempts to use a version range to match against future experimental releases. The only way to install or depend on an experimental release is to refer to the specific version number. Building -------- I did not use the existing feature flag infra to configure the experimental builds. The reason is because feature flags are designed to configure a single package. They're not designed to generate multiple forks of the same package; for each set of feature flags, you must create a separate package configuration. Instead, I've added a new build dimension called the **release channel**. By default, builds use the **stable** channel. There's also an **experimental** release channel. We have the option to add more in the future. There are now two dimensions per artifact: build type (production, development, or profiling), and release channel (stable or experimental). These are separate dimensions because they are combinatorial: there are stable and experimental production builds, stable and experimental developmenet builds, and so on. You can add something to an experimental build by gating on `__EXPERIMENTAL__`, similar to how we use `__DEV__`. Anything inside these branches will be excluded from the stable builds. This gives us a low effort way to add experimental behavior in any package without setting up feature flags or configuring a new package.
2019-10-15 01:46:42 +08:00
const reactVersion = isExperimental
? `${packageJSON.version}-experimental-${commit}-${dateString}`
: `${packageJSON.version}-${commit}-${dateString}`;
return {branch, buildNumber, checksum, commit, reactVersion, version};
};
const getChecksumForCurrentRevision = async cwd => {
const packagesDir = join(cwd, 'packages');
const hashedPackages = await hashElement(packagesDir, {
encoding: 'hex',
files: {exclude: ['.DS_Store']},
});
return hashedPackages.hash.slice(0, 7);
};
const getDateStringForCommit = async commit => {
let dateString = await execRead(
`git show -s --no-show-signature --format=%cd --date=format:%Y%m%d ${commit}`
);
// On CI environment, this string is wrapped with quotes '...'s
if (dateString.startsWith("'")) {
dateString = dateString.substr(1, 8);
}
return dateString;
};
const getCommitFromCurrentBuild = async () => {
const cwd = join(__dirname, '..', '..');
// If this build includes a build-info.json file, extract the commit from it.
// Otherwise fall back to parsing from the package version number.
// This is important to make the build reproducible (e.g. by Mozilla reviewers).
const buildInfoJSON = join(
cwd,
'build',
'oss-experimental',
'react',
'build-info.json'
);
if (existsSync(buildInfoJSON)) {
const buildInfo = await readJson(buildInfoJSON);
return buildInfo.commit;
} else {
const packageJSON = join(
cwd,
'build',
'oss-experimental',
'react',
'package.json'
);
const {version} = await readJson(packageJSON);
return extractCommitFromVersionNumber(version);
}
};
const getPublicPackages = isExperimental => {
const packageNames = Object.keys(stablePackages);
if (isExperimental) {
packageNames.push(...experimentalPackages);
}
return packageNames;
};
const handleError = error => {
logUpdate.clear();
const message = error.message.trim().replace(/\n +/g, '\n');
const stack = error.stack.replace(error.message, '');
console.log(theme`{error ${message}}\n\n{path ${stack}}`);
process.exit(1);
};
const logPromise = async (promise, text, estimate) =>
logger(promise, text, {estimate});
const printDiff = (path, beforeContents, afterContents) => {
const patch = createPatch(path, beforeContents, afterContents);
const coloredLines = patch
.split('\n')
.slice(2) // Trim index file
.map((line, index) => {
if (index <= 1) {
return theme.diffHeader(line);
}
switch (line[0]) {
case '+':
return theme.diffAdded(line);
case '-':
return theme.diffRemoved(line);
case ' ':
return line;
case '@':
return null;
case '\\':
return null;
}
})
.filter(line => line);
console.log(coloredLines.join('\n'));
return patch;
};
// Convert an array param (expected format "--foo bar baz")
// to also accept comma input (e.g. "--foo bar,baz")
const splitCommaParams = array => {
for (let i = array.length - 1; i >= 0; i--) {
const param = array[i];
if (param.includes(',')) {
array.splice(i, 1, ...param.split(','));
}
}
};
// This method is used by both local Node release scripts and Circle CI bash scripts.
// It updates version numbers in package JSONs (both the version field and dependencies),
// As well as the embedded renderer version in "packages/shared/ReactVersion".
// Canaries version numbers use the format of 0.0.0-<sha>-<date> to be easily recognized (e.g. 0.0.0-01974a867-20200129).
// A separate "React version" is used for the embedded renderer version to support DevTools,
// since it needs to distinguish between different version ranges of React.
// It is based on the version of React in the local package.json (e.g. 16.12.0-01974a867-20200129).
// Both numbers will be replaced if the "next" release is promoted to a stable release.
const updateVersionsForNext = async (cwd, reactVersion, version) => {
const isExperimental = reactVersion.includes('experimental');
const packages = getPublicPackages(isExperimental);
const packagesDir = join(cwd, 'packages');
// Update the shared React version source file.
// This is bundled into built renderers.
// The promote script will replace this with a final version later.
const sourceReactVersionPath = join(cwd, 'packages/shared/ReactVersion.js');
const sourceReactVersion = readFileSync(
sourceReactVersionPath,
'utf8'
).replace(/export default '[^']+';/, `export default '${reactVersion}';`);
writeFileSync(sourceReactVersionPath, sourceReactVersion);
// Update the root package.json.
// This is required to pass a later version check script.
{
const packageJSONPath = join(cwd, 'package.json');
const packageJSON = await readJson(packageJSONPath);
packageJSON.version = version;
await writeJson(packageJSONPath, packageJSON, {spaces: 2});
}
for (let i = 0; i < packages.length; i++) {
const packageName = packages[i];
const packagePath = join(packagesDir, packageName);
// Update version numbers in package JSONs
const packageJSONPath = join(packagePath, 'package.json');
const packageJSON = await readJson(packageJSONPath);
packageJSON.version = version;
// Also update inter-package dependencies.
// Next releases always have exact version matches.
// The promote script may later relax these (e.g. "^x.x.x") based on source package JSONs.
const {dependencies, peerDependencies} = packageJSON;
for (let j = 0; j < packages.length; j++) {
const dependencyName = packages[j];
if (dependencies && dependencies[dependencyName]) {
dependencies[dependencyName] = version;
}
if (peerDependencies && peerDependencies[dependencyName]) {
peerDependencies[dependencyName] = version;
}
}
await writeJson(packageJSONPath, packageJSON, {spaces: 2});
}
};
module.exports = {
addDefaultParamValue,
confirm,
execRead,
getArtifactsList,
getBuildInfo,
getChecksumForCurrentRevision,
getCommitFromCurrentBuild,
getDateStringForCommit,
getPublicPackages,
handleError,
logPromise,
printDiff,
splitCommaParams,
theme,
updateVersionsForNext,
};