react-native-macos/scripts/publish-npm.js

176 строки
4.8 KiB
JavaScript
Исходник Обычный вид История

/**
* Copyright (c) Meta Platforms, Inc. and affiliates.
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
*
* @format
*/
'use strict';
/**
* This script prepares a release version of react-native and may publish to NPM.
* It is supposed to run in CI environment, not on a developer's machine.
*
* For a dry run (commitly), this script will:
* * Version the commitly of the form `1000.0.0-<commitSha>`
* * Create Android artifacts
* * It will not publish to npm
*
* For a nightly run, this script will:
* * Version the nightly release of the form `0.0.0-<dateIdentifier>-<commitSha>`
* * Create Android artifacts
* * Publish to npm using `nightly` tag
*
* For a release run, this script will:
* * Version the release by the tag version that triggered CI
* * Create Android artifacts
* * Publish to npm
* * using `latest` tag if commit is currently tagged `latest`
* * or otherwise `{major}.{minor}-stable`
*/
infra(e2e): rework local E2E script (#34513) Summary: This is a long time coming effort to improve the situation around the local e2e script that in the release crew: the current bash-based script is quirky at best, and what you end up generating as a sample project is not really a true sample project. This is where this PR comes in: it migrates the flow from `./scripts/test-manual-e2e.sh` to `yarn test-e2e-local <options>`. Here's the current shape of the options: ```sh Options: --help Show help [boolean] --version Show version number [boolean] -t, --target [choices: "RNTester", "RNTestProject"] [default: "RNTester"] -p, --platform [choices: "iOS", "Android"] [default: "iOS"] -h, --hermes [boolean] [default: true] ``` The idea is to change it so that you can just run the script, and it will do that one specific thing "well", without the tester needing to do anything aside from actually testing the app once it's open. Some of the key changes: * tries to stick to the patterns of the other established *.js based scripts, in terms of tooling and approach (and even refactor parts that can be shared with other scripts) - like the android artifacts generation * no need to start the android emulator on the side * no need to start Metro on the side * RNTester iOS will open up on the simulator (no Xcode open that then you need to press) Things that still need work: * see the #fixme and #todo in comments * because we rely on exec, the output sent back is not formatted/shaped correctly so it's a bit more noisy/chaotic - but can't handle it right now because the package we use doesn't allow it - see https://github.com/shelljs/shelljs/issues/86 ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://reactnative.dev/contributing/changelogs-in-pull-requests --> [Internal] [Changed] - Migrate bash E2E local testing script to new JS based command Pull Request resolved: https://github.com/facebook/react-native/pull/34513 Test Plan: To test the script, you can run it passing the options showed above; this is the current situation: * RNTester iOS Hermes ✅ * RNTester Android Hermes ✅ * RNTester iOS JSC ✅ * RNTester Android JSC ✅ * RNTestProject Android Hermes ✅ * RNTestProject iOS Hermes ✅ * RNTestProject Android JSC ✅ * RNTestProject iOS JSC ✅ Reviewed By: cortinico Differential Revision: D39814692 Pulled By: cortinico fbshipit-source-id: d4791798aaad764c6a3757269b7636f847ccf2ca
2022-10-04 14:56:44 +03:00
const {exec, echo, exit} = require('shelljs');
const {parseVersion} = require('./version-utils');
const {
exitIfNotOnGit,
getCurrentCommit,
isTaggedLatest,
} = require('./scm-utils');
infra(e2e): rework local E2E script (#34513) Summary: This is a long time coming effort to improve the situation around the local e2e script that in the release crew: the current bash-based script is quirky at best, and what you end up generating as a sample project is not really a true sample project. This is where this PR comes in: it migrates the flow from `./scripts/test-manual-e2e.sh` to `yarn test-e2e-local <options>`. Here's the current shape of the options: ```sh Options: --help Show help [boolean] --version Show version number [boolean] -t, --target [choices: "RNTester", "RNTestProject"] [default: "RNTester"] -p, --platform [choices: "iOS", "Android"] [default: "iOS"] -h, --hermes [boolean] [default: true] ``` The idea is to change it so that you can just run the script, and it will do that one specific thing "well", without the tester needing to do anything aside from actually testing the app once it's open. Some of the key changes: * tries to stick to the patterns of the other established *.js based scripts, in terms of tooling and approach (and even refactor parts that can be shared with other scripts) - like the android artifacts generation * no need to start the android emulator on the side * no need to start Metro on the side * RNTester iOS will open up on the simulator (no Xcode open that then you need to press) Things that still need work: * see the #fixme and #todo in comments * because we rely on exec, the output sent back is not formatted/shaped correctly so it's a bit more noisy/chaotic - but can't handle it right now because the package we use doesn't allow it - see https://github.com/shelljs/shelljs/issues/86 ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://reactnative.dev/contributing/changelogs-in-pull-requests --> [Internal] [Changed] - Migrate bash E2E local testing script to new JS based command Pull Request resolved: https://github.com/facebook/react-native/pull/34513 Test Plan: To test the script, you can run it passing the options showed above; this is the current situation: * RNTester iOS Hermes ✅ * RNTester Android Hermes ✅ * RNTester iOS JSC ✅ * RNTester Android JSC ✅ * RNTestProject Android Hermes ✅ * RNTestProject iOS Hermes ✅ * RNTestProject Android JSC ✅ * RNTestProject iOS JSC ✅ Reviewed By: cortinico Differential Revision: D39814692 Pulled By: cortinico fbshipit-source-id: d4791798aaad764c6a3757269b7636f847ccf2ca
2022-10-04 14:56:44 +03:00
const {
generateAndroidArtifacts,
publishAndroidArtifactsToMaven,
infra(e2e): rework local E2E script (#34513) Summary: This is a long time coming effort to improve the situation around the local e2e script that in the release crew: the current bash-based script is quirky at best, and what you end up generating as a sample project is not really a true sample project. This is where this PR comes in: it migrates the flow from `./scripts/test-manual-e2e.sh` to `yarn test-e2e-local <options>`. Here's the current shape of the options: ```sh Options: --help Show help [boolean] --version Show version number [boolean] -t, --target [choices: "RNTester", "RNTestProject"] [default: "RNTester"] -p, --platform [choices: "iOS", "Android"] [default: "iOS"] -h, --hermes [boolean] [default: true] ``` The idea is to change it so that you can just run the script, and it will do that one specific thing "well", without the tester needing to do anything aside from actually testing the app once it's open. Some of the key changes: * tries to stick to the patterns of the other established *.js based scripts, in terms of tooling and approach (and even refactor parts that can be shared with other scripts) - like the android artifacts generation * no need to start the android emulator on the side * no need to start Metro on the side * RNTester iOS will open up on the simulator (no Xcode open that then you need to press) Things that still need work: * see the #fixme and #todo in comments * because we rely on exec, the output sent back is not formatted/shaped correctly so it's a bit more noisy/chaotic - but can't handle it right now because the package we use doesn't allow it - see https://github.com/shelljs/shelljs/issues/86 ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://reactnative.dev/contributing/changelogs-in-pull-requests --> [Internal] [Changed] - Migrate bash E2E local testing script to new JS based command Pull Request resolved: https://github.com/facebook/react-native/pull/34513 Test Plan: To test the script, you can run it passing the options showed above; this is the current situation: * RNTester iOS Hermes ✅ * RNTester Android Hermes ✅ * RNTester iOS JSC ✅ * RNTester Android JSC ✅ * RNTestProject Android Hermes ✅ * RNTestProject iOS Hermes ✅ * RNTestProject Android JSC ✅ * RNTestProject iOS JSC ✅ Reviewed By: cortinico Differential Revision: D39814692 Pulled By: cortinico fbshipit-source-id: d4791798aaad764c6a3757269b7636f847ccf2ca
2022-10-04 14:56:44 +03:00
} = require('./release-utils');
const fs = require('fs');
const os = require('os');
const path = require('path');
const yargs = require('yargs');
const buildTag = process.env.CIRCLE_TAG;
const otp = process.env.NPM_CONFIG_OTP;
const tmpPublishingFolder = fs.mkdtempSync(
path.join(os.tmpdir(), 'rn-publish-'),
);
const argv = yargs
.option('n', {
alias: 'nightly',
type: 'boolean',
default: false,
})
.option('d', {
alias: 'dry-run',
type: 'boolean',
default: false,
})
.option('r', {
alias: 'release', // useless but needed for CI
type: 'boolean',
default: false,
})
.strict().argv;
const nightlyBuild = argv.nightly;
const dryRunBuild = argv.dryRun;
const isCommitly = nightlyBuild || dryRunBuild;
if (!argv.help) {
echo(`The temp publishing folder is ${tmpPublishingFolder}`);
}
// 34c034298dc9cad5a4553964a5a324450fda0385
const currentCommit = getCurrentCommit();
const shortCommit = currentCommit.slice(0, 9);
const rawVersion =
// 0.0.0 triggers issues with cocoapods for codegen when building template project.
dryRunBuild
? '1000.0.0'
: // For nightly we continue to use 0.0.0 for clarity for npm
nightlyBuild
? '0.0.0'
: // For pre-release and stable releases, we use the git tag of the version we're releasing (set in bump-oss-version)
buildTag;
let version,
Fix npm latest tag issue when releasing patches (#32543) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/32543 Changelog: [Internal] Fix npm `latest` tag issue that occurs when we release a patch on an older minor version Context: * There are two types of tags, git and npm, they are unrelated. * When we publish a stable release, we set the git tag `latest`. This logic is faulty when we release a patch to an older version. * When publishing a package to npm, if you don't provide an explicit tag, the `latest` tag will be applied -- at least that's how I've understood the [docs here](https://docs.npmjs.com/cli/v7/commands/npm-dist-tag#description). This again is faulty logic when we release a patch to an older version. * npm and git's `latest` tag should always point to our most recent stable version This change: * Introduces a `--latest` flag for `bump-oss-script` that will indicate that the release we're running (either a stable or pre-release) should really be considered "latest" * If the version is not a pre-release and the `--latest` flag is set, we will set the git `latest` tag * Later, in the circleCI job that we use to publish the npm package, we will see if the current commit is git-tagged as `latest`. If it is, then we'll explicitly tell npm to use `latest` tag but most importantly, if it's not, we'll set a tag of the form `{major}.{minor}-stable`. * This type of tag (ex. `0.66-stable`) is new and the intention is that it will always point to latest of that minor version. Reviewed By: hramos Differential Revision: D32196239 fbshipit-source-id: 4c881851eebcad8585732ff0c07322413ac46ce5
2021-11-06 01:07:02 +03:00
major,
minor,
prerelease = null;
try {
Fix npm latest tag issue when releasing patches (#32543) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/32543 Changelog: [Internal] Fix npm `latest` tag issue that occurs when we release a patch on an older minor version Context: * There are two types of tags, git and npm, they are unrelated. * When we publish a stable release, we set the git tag `latest`. This logic is faulty when we release a patch to an older version. * When publishing a package to npm, if you don't provide an explicit tag, the `latest` tag will be applied -- at least that's how I've understood the [docs here](https://docs.npmjs.com/cli/v7/commands/npm-dist-tag#description). This again is faulty logic when we release a patch to an older version. * npm and git's `latest` tag should always point to our most recent stable version This change: * Introduces a `--latest` flag for `bump-oss-script` that will indicate that the release we're running (either a stable or pre-release) should really be considered "latest" * If the version is not a pre-release and the `--latest` flag is set, we will set the git `latest` tag * Later, in the circleCI job that we use to publish the npm package, we will see if the current commit is git-tagged as `latest`. If it is, then we'll explicitly tell npm to use `latest` tag but most importantly, if it's not, we'll set a tag of the form `{major}.{minor}-stable`. * This type of tag (ex. `0.66-stable`) is new and the intention is that it will always point to latest of that minor version. Reviewed By: hramos Differential Revision: D32196239 fbshipit-source-id: 4c881851eebcad8585732ff0c07322413ac46ce5
2021-11-06 01:07:02 +03:00
({version, major, minor, prerelease} = parseVersion(rawVersion));
} catch (e) {
echo(e.message);
exit(1);
}
let releaseVersion;
if (dryRunBuild) {
releaseVersion = `${version}-${shortCommit}`;
} else if (nightlyBuild) {
// 2021-09-28T05:38:40.669Z -> 20210928-0538
const dateIdentifier = new Date()
.toISOString()
.slice(0, -8)
.replace(/[-:]/g, '')
.replace(/[T]/g, '-');
releaseVersion = `${version}-${dateIdentifier}-${shortCommit}`;
} else {
releaseVersion = version;
}
// Bump version number in various files (package.json, gradle.properties etc)
// For stable, pre-release releases, we rely on CircleCI job `prepare_package_for_release` to handle this
if (isCommitly) {
if (
exec(`node scripts/set-rn-version.js --to-version ${releaseVersion}`).code
) {
echo(`Failed to set version number to ${releaseVersion}`);
exit(1);
}
}
infra(e2e): rework local E2E script (#34513) Summary: This is a long time coming effort to improve the situation around the local e2e script that in the release crew: the current bash-based script is quirky at best, and what you end up generating as a sample project is not really a true sample project. This is where this PR comes in: it migrates the flow from `./scripts/test-manual-e2e.sh` to `yarn test-e2e-local <options>`. Here's the current shape of the options: ```sh Options: --help Show help [boolean] --version Show version number [boolean] -t, --target [choices: "RNTester", "RNTestProject"] [default: "RNTester"] -p, --platform [choices: "iOS", "Android"] [default: "iOS"] -h, --hermes [boolean] [default: true] ``` The idea is to change it so that you can just run the script, and it will do that one specific thing "well", without the tester needing to do anything aside from actually testing the app once it's open. Some of the key changes: * tries to stick to the patterns of the other established *.js based scripts, in terms of tooling and approach (and even refactor parts that can be shared with other scripts) - like the android artifacts generation * no need to start the android emulator on the side * no need to start Metro on the side * RNTester iOS will open up on the simulator (no Xcode open that then you need to press) Things that still need work: * see the #fixme and #todo in comments * because we rely on exec, the output sent back is not formatted/shaped correctly so it's a bit more noisy/chaotic - but can't handle it right now because the package we use doesn't allow it - see https://github.com/shelljs/shelljs/issues/86 ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://reactnative.dev/contributing/changelogs-in-pull-requests --> [Internal] [Changed] - Migrate bash E2E local testing script to new JS based command Pull Request resolved: https://github.com/facebook/react-native/pull/34513 Test Plan: To test the script, you can run it passing the options showed above; this is the current situation: * RNTester iOS Hermes ✅ * RNTester Android Hermes ✅ * RNTester iOS JSC ✅ * RNTester Android JSC ✅ * RNTestProject Android Hermes ✅ * RNTestProject iOS Hermes ✅ * RNTestProject Android JSC ✅ * RNTestProject iOS JSC ✅ Reviewed By: cortinico Differential Revision: D39814692 Pulled By: cortinico fbshipit-source-id: d4791798aaad764c6a3757269b7636f847ccf2ca
2022-10-04 14:56:44 +03:00
generateAndroidArtifacts(releaseVersion, tmpPublishingFolder);
// Write version number to the build folder
const releaseVersionFile = path.join('build', '.version');
fs.writeFileSync(releaseVersionFile, releaseVersion);
if (dryRunBuild) {
echo('Skipping `npm publish` because --dry-run is set.');
exit(0);
}
Fix npm latest tag issue when releasing patches (#32543) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/32543 Changelog: [Internal] Fix npm `latest` tag issue that occurs when we release a patch on an older minor version Context: * There are two types of tags, git and npm, they are unrelated. * When we publish a stable release, we set the git tag `latest`. This logic is faulty when we release a patch to an older version. * When publishing a package to npm, if you don't provide an explicit tag, the `latest` tag will be applied -- at least that's how I've understood the [docs here](https://docs.npmjs.com/cli/v7/commands/npm-dist-tag#description). This again is faulty logic when we release a patch to an older version. * npm and git's `latest` tag should always point to our most recent stable version This change: * Introduces a `--latest` flag for `bump-oss-script` that will indicate that the release we're running (either a stable or pre-release) should really be considered "latest" * If the version is not a pre-release and the `--latest` flag is set, we will set the git `latest` tag * Later, in the circleCI job that we use to publish the npm package, we will see if the current commit is git-tagged as `latest`. If it is, then we'll explicitly tell npm to use `latest` tag but most importantly, if it's not, we'll set a tag of the form `{major}.{minor}-stable`. * This type of tag (ex. `0.66-stable`) is new and the intention is that it will always point to latest of that minor version. Reviewed By: hramos Differential Revision: D32196239 fbshipit-source-id: 4c881851eebcad8585732ff0c07322413ac46ce5
2021-11-06 01:07:02 +03:00
// Running to see if this commit has been git tagged as `latest`
const isLatest = exitIfNotOnGit(
() => isTaggedLatest(currentCommit),
'Not in git. We do not want to publish anything',
);
Fix npm latest tag issue when releasing patches (#32543) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/32543 Changelog: [Internal] Fix npm `latest` tag issue that occurs when we release a patch on an older minor version Context: * There are two types of tags, git and npm, they are unrelated. * When we publish a stable release, we set the git tag `latest`. This logic is faulty when we release a patch to an older version. * When publishing a package to npm, if you don't provide an explicit tag, the `latest` tag will be applied -- at least that's how I've understood the [docs here](https://docs.npmjs.com/cli/v7/commands/npm-dist-tag#description). This again is faulty logic when we release a patch to an older version. * npm and git's `latest` tag should always point to our most recent stable version This change: * Introduces a `--latest` flag for `bump-oss-script` that will indicate that the release we're running (either a stable or pre-release) should really be considered "latest" * If the version is not a pre-release and the `--latest` flag is set, we will set the git `latest` tag * Later, in the circleCI job that we use to publish the npm package, we will see if the current commit is git-tagged as `latest`. If it is, then we'll explicitly tell npm to use `latest` tag but most importantly, if it's not, we'll set a tag of the form `{major}.{minor}-stable`. * This type of tag (ex. `0.66-stable`) is new and the intention is that it will always point to latest of that minor version. Reviewed By: hramos Differential Revision: D32196239 fbshipit-source-id: 4c881851eebcad8585732ff0c07322413ac46ce5
2021-11-06 01:07:02 +03:00
// We first publish on Maven Central all the necessary artifacts.
// NPM publishing is done just after.
publishAndroidArtifactsToMaven(releaseVersion, nightlyBuild);
Fix npm latest tag issue when releasing patches (#32543) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/32543 Changelog: [Internal] Fix npm `latest` tag issue that occurs when we release a patch on an older minor version Context: * There are two types of tags, git and npm, they are unrelated. * When we publish a stable release, we set the git tag `latest`. This logic is faulty when we release a patch to an older version. * When publishing a package to npm, if you don't provide an explicit tag, the `latest` tag will be applied -- at least that's how I've understood the [docs here](https://docs.npmjs.com/cli/v7/commands/npm-dist-tag#description). This again is faulty logic when we release a patch to an older version. * npm and git's `latest` tag should always point to our most recent stable version This change: * Introduces a `--latest` flag for `bump-oss-script` that will indicate that the release we're running (either a stable or pre-release) should really be considered "latest" * If the version is not a pre-release and the `--latest` flag is set, we will set the git `latest` tag * Later, in the circleCI job that we use to publish the npm package, we will see if the current commit is git-tagged as `latest`. If it is, then we'll explicitly tell npm to use `latest` tag but most importantly, if it's not, we'll set a tag of the form `{major}.{minor}-stable`. * This type of tag (ex. `0.66-stable`) is new and the intention is that it will always point to latest of that minor version. Reviewed By: hramos Differential Revision: D32196239 fbshipit-source-id: 4c881851eebcad8585732ff0c07322413ac46ce5
2021-11-06 01:07:02 +03:00
const releaseBranch = `${major}.${minor}-stable`;
// Set the right tag for nightly and prerelease builds
Fix npm latest tag issue when releasing patches (#32543) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/32543 Changelog: [Internal] Fix npm `latest` tag issue that occurs when we release a patch on an older minor version Context: * There are two types of tags, git and npm, they are unrelated. * When we publish a stable release, we set the git tag `latest`. This logic is faulty when we release a patch to an older version. * When publishing a package to npm, if you don't provide an explicit tag, the `latest` tag will be applied -- at least that's how I've understood the [docs here](https://docs.npmjs.com/cli/v7/commands/npm-dist-tag#description). This again is faulty logic when we release a patch to an older version. * npm and git's `latest` tag should always point to our most recent stable version This change: * Introduces a `--latest` flag for `bump-oss-script` that will indicate that the release we're running (either a stable or pre-release) should really be considered "latest" * If the version is not a pre-release and the `--latest` flag is set, we will set the git `latest` tag * Later, in the circleCI job that we use to publish the npm package, we will see if the current commit is git-tagged as `latest`. If it is, then we'll explicitly tell npm to use `latest` tag but most importantly, if it's not, we'll set a tag of the form `{major}.{minor}-stable`. * This type of tag (ex. `0.66-stable`) is new and the intention is that it will always point to latest of that minor version. Reviewed By: hramos Differential Revision: D32196239 fbshipit-source-id: 4c881851eebcad8585732ff0c07322413ac46ce5
2021-11-06 01:07:02 +03:00
// If a release is not git-tagged as `latest` we use `releaseBranch` to prevent
// npm from overriding the current `latest` version tag, which it will do if no tag is set.
const tagFlag = nightlyBuild
? '--tag nightly'
: prerelease != null
? '--tag next'
Fix npm latest tag issue when releasing patches (#32543) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/32543 Changelog: [Internal] Fix npm `latest` tag issue that occurs when we release a patch on an older minor version Context: * There are two types of tags, git and npm, they are unrelated. * When we publish a stable release, we set the git tag `latest`. This logic is faulty when we release a patch to an older version. * When publishing a package to npm, if you don't provide an explicit tag, the `latest` tag will be applied -- at least that's how I've understood the [docs here](https://docs.npmjs.com/cli/v7/commands/npm-dist-tag#description). This again is faulty logic when we release a patch to an older version. * npm and git's `latest` tag should always point to our most recent stable version This change: * Introduces a `--latest` flag for `bump-oss-script` that will indicate that the release we're running (either a stable or pre-release) should really be considered "latest" * If the version is not a pre-release and the `--latest` flag is set, we will set the git `latest` tag * Later, in the circleCI job that we use to publish the npm package, we will see if the current commit is git-tagged as `latest`. If it is, then we'll explicitly tell npm to use `latest` tag but most importantly, if it's not, we'll set a tag of the form `{major}.{minor}-stable`. * This type of tag (ex. `0.66-stable`) is new and the intention is that it will always point to latest of that minor version. Reviewed By: hramos Differential Revision: D32196239 fbshipit-source-id: 4c881851eebcad8585732ff0c07322413ac46ce5
2021-11-06 01:07:02 +03:00
: isLatest
? '--tag latest'
: `--tag ${releaseBranch}`;
// use otp from envvars if available
const otpFlag = otp ? `--otp ${otp}` : '';
if (exec(`npm publish ${tagFlag} ${otpFlag}`).code) {
echo('Failed to publish package to npm');
exit(1);
} else {
echo(`Published to npm ${releaseVersion}`);
exit(0);
}