{"_id":"@2060.io/semantic-release-react-native","name":"@2060.io/semantic-release-react-native","dist-tags":{"latest":"1.11.0"},"versions":{"1.11.0":{"name":"@2060.io/semantic-release-react-native","version":"1.11.0","description":"Semantic Release plugin for versioning React Native applications.","author":{"name":"Alex Mendes"},"license":"ISC","main":"index.js","scripts":{"build":"tsc -d","prebuild":"rimraf dist","test":"jest","lint":"eslint .","prepublishOnly":"yarn build"},"repository":{"type":"git","url":"git+https://github.com/alexandermendes/semantic-release-react-native.git"},"homepage":"https://github.com/alexandermendes/semantic-release-react-native#readme","bugs":{"url":"https://github.com/alexandermendes/semantic-release-react-native/issues"},"husky":{"hooks":{"commit-msg":"commitlint -E HUSKY_GIT_PARAMS"}},"keywords":["semantic-release","react-native","version","release","prepare"],"peerDependencies":{"semantic-release":"*"},"dependencies":{"app-root-path":"^3.0.0","deepmerge":"^4.2.2","detect-indent":"^6.1.0","html-minifier":"^4.0.0","js-beautify":"^1.14.5","lodash.flattendeep":"^4.4.0","lodash.uniq":"^4.5.0","pbxproj-dom":"^1.2.0","plist":"^3.0.6","semver":"^7.3.7"},"devDependencies":{"@commitlint/config-conventional":"^16.0.0","@semantic-release/changelog":"^6.0.1","@semantic-release/git":"^10.0.1","@types/app-root-path":"^1.2.4","@types/html-minifier":"^4.0.2","@types/jest":"^27.4.0","@types/js-beautify":"^1.13.3","@types/lodash.flattendeep":"^4.4.7","@types/lodash.uniq":"^4.5.7","@types/plist":"^3.0.2","@types/semantic-release":"^17.2.4","@types/semver":"^7.3.12","@typescript-eslint/eslint-plugin":"^5.11.0","@typescript-eslint/parser":"^5.11.0","commitlint":"^8.3.5","eslint":"^8.8.0","eslint-config-airbnb-base":"^15.0.0","eslint-plugin-import":"^2.25.4","eslint-plugin-jest":"^26.0.0","husky":"^4.2.5","jest":"^27.5.1","rimraf":"^3.0.2","semantic-release":"^19.0.2","ts-jest":"^27.0.4","typescript":"^4.3.5"},"publishConfig":{"access":"public"},"_id":"@2060.io/semantic-release-react-native@1.11.0","gitHead":"70fa632debb67629ea9cb2d6b8a4d7ecb74433ce","_nodeVersion":"20.12.2","_npmVersion":"10.5.0","dist":{"integrity":"sha512-hbfNNzEpfxusPlKEn2WwES/3VpANT4YUA6GVMRQGOsRcqxsbfgxgH/hh8roXrATJuFQ7GmAvBCKxR+ECcJTvtQ==","shasum":"1464ad70efc6ff9eac1e994fe864db0e9c6ecbb7","tarball":"https://registry.npmjs.org/@2060.io/semantic-release-react-native/-/semantic-release-react-native-1.11.0.tgz","fileCount":43,"unpackedSize":91347,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCXRLx+Dh41tcXNIhzHJadmx23EdqGisxDuxkqk2xyGYwIgPHbisCFz5bbcfw2ItPvZTFvDBu1NFokDU61X1wracsk="}]},"_npmUser":{"name":"genaris","email":"gentilester@gmail.com"},"directories":{},"maintainers":[{"name":"genaris","email":"gentilester@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/semantic-release-react-native_1.11.0_1726765952961_0.2774134897051208"},"_hasShrinkwrap":false}},"time":{"created":"2024-09-19T17:12:32.847Z","1.11.0":"2024-09-19T17:12:33.151Z","modified":"2024-09-19T17:12:33.459Z"},"maintainers":[{"name":"genaris","email":"gentilester@gmail.com"}],"description":"Semantic Release plugin for versioning React Native applications.","homepage":"https://github.com/alexandermendes/semantic-release-react-native#readme","keywords":["semantic-release","react-native","version","release","prepare"],"repository":{"type":"git","url":"git+https://github.com/alexandermendes/semantic-release-react-native.git"},"author":{"name":"Alex Mendes"},"bugs":{"url":"https://github.com/alexandermendes/semantic-release-react-native/issues"},"license":"ISC","readme":"# semantic-release-react-native\n\n[![npm version](https://badge.fury.io/js/semantic-release-react-native.svg)](https://badge.fury.io/js/semantic-release-react-native)\n\nA [Semantic Release](https://github.com/semantic-release/semantic-release) plugin\nfor versioning [React Native](https://reactnative.dev/) applications.\n\n| Step               | Description                           |\n|--------------------|---------------------------------------|\n| `verifyConditions` | Validate configuration.               |\n| `prepare`          | Version native iOS and Android files. |\n\n## Installation\n\n```sh\nnpm install semantic-release-react-native -D\n```\n\n## Usage\n\nThe plugin can be configured in the [Semantic Release configuration file](https://github.com/semantic-release/semantic-release/blob/master/docs/usage/configuration.md#configuration):\n\n```json\n{\n  \"plugins\": [\n    \"@semantic-release/commit-analyzer\",\n    \"semantic-release-react-native\",\n    [\n      \"@semantic-release/git\",\n      {\n        \"assets\": [\n          \"ios/**/Info.plist\",\n          \"ios/**/*.pbxproj\",\n          \"android/app/build.gradle\",\n        ],\n      },\n    ],\n  ]\n}\n```\n\nThe example configuration above will version and git commit your native files.\n\n## Configuration\n\n| Property          | Description                                                        | Default                    |\n|-------------------|--------------------------------------------------------------------|----------------------------|\n| `androidPath`     | Path to your \"android/app/build.gradle\" file.                      | `android/app/build.gradle` |\n| `iosPath`         | Path to your \"ios/\" folder.                                        | `ios`                      |\n| `skipBuildNumber` | Do not increment the build number for either platform.             | `false`                    |\n| `skipAndroid`     | Skip Android versioning.                                           | `false`                    |\n| `skipIos`         | Skip iOS versioning.                                               | `false`                    |\n| `iosPackageName`  | Only update iOS projects that have the given name.                 | `null`                     |\n| `noPrerelease`    | Skip pre-release versions entirely for both platforms.             | `false`                    |\n| `versionStrategy` | Specifies the versioning strategies for each platform (see below). | `{\"android\": {\"buildNumber\": \"increment\", \"preRelease\": true}, \"ios\": {\"buildNumber\": \"strict\", \"preRelease\": true}}` |\n\n## Versioning strategies\n\nBy default this plugin will set the `vesionName` for Android and the\n`CFBundleShortVersionString` for iOS to the version defined as the next semantic\nrelease.\n\nSetting the `vesionCode` for Android and the `CFBundleVersion` for iOS becomes\na little more complicated due to differences between how the platforms use these\nproperties.\n\nThis plugin uses sensible defaults for each platform. However, these defaults may\nnot work for you if introducing this plugin to a project that was already\nversioned in an entirely different way, or if you just have a different personal\npreference. In order to provide suitable flexibility various alternative\nstrategies are available for each platform.\n\n**Example (defaults shown)**\n\n```json\n{\n  \"plugins\": [\n    [\"semantic-release-react-native\", {\n      \"versionStrategy\": {\n        \"android\": { \"buildNumber\": \"increment\" },\n        \"ios\": { \"buildNumber\": \"strict\" }\n      }\n    }],\n  ]\n}\n```\n\n### Android\n\nFor Android, the `versionCode` is an integer that must be incremented in some\nway with every version of the app. The maximum value currently allowed by the\nGoogle Play Store is 2100000000. The available strategies for achieving this\nare described below.\n\n#### `increment`\n\nThis is the default strategy for this platform.\n\nIt auto-increments the current `versionCode` by one for every release.\n\n#### `relative`\n\nUpdate the `versionCode` in-line with the next semantic version. For example,\n`v1.25.3` becomes `12503`, with each number in the semantic release version\nconverted to two digits and the start of each number padded with zeros as necessary.\nAny leading zeros are then stripped to avoid Android encoding as an octal number.\n\nThe downside to this approach is that it effectively breaks when we hit MINOR\nor PATCH versions greater than 99. When we get to version `v1.100.1`, for example,\nwe would have to make a decision about whether or not we allow three digits, in\nwhich case this becomes `110001` and will break when we release version `2.0.0`\n(as `1010001` > `20000`). Or we could choose to only allow two digits and strip\nthe last, in which case this will break when we release version `v1.101.1`\n(as in both cases the `versionCode` would equal `11001`).\n\nIf you think you are unlikely to have 100 MINOR or PATCH versions then go ahead\nand use this strategy.\n\n#### `relative-extended`\n\nThis is similar to the `semantic` strategy described above, yet with the addition\nof the minumum API level as the first two digits, followed by a zero. It also\nfaces the same downsides as the `semantic` strategy.\n\n#### `env`\n\nRead `versionCode` from environment variable `ANDROID_BUILD_NUMBER`.\n\n#### `none`\n\nDisable updates of the `versionCode`.\n\n### iOS\n\nThe strategies for iOS are perhaps even more confusing due to the amount of\nconflicting information out there about what constitutes a technically correct\n`CFBundleVersion`, with Apple's own documentation suggesting different\nrestrictions in different places.\n\nThe general consensus seems to be that it should be a string comprised of three\nnon-negative, period-separated integers. There also seem to be plenty of projects\nthat have used just a single integer, apparently without issue. However, just\nbecause these projects haven't encountered issues it doesn't mean they never will.\nFor example, [the documentation](https://developer.apple.com/library/archive/technotes/tn2413/_index.html#//apple_ref/doc/uid/DTS40016228-CH1-TROUBLESHOOTING-CALLING_THE_PAYMENT_QUEUE___S_RESTORECOMPLETEDTRANSACTIONS_METHOD_DOES_NOT_RESTORE_ANY_PRODUCTS_IN_MY_APPLICATION) states that it may be impossible to restore\nIn App Purchases if the `CFBundleVersion` does not follow [the guidelines](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/20001431-102364) for build numbers.\n\nWith all that said, the available strategies are described below.\n\n#### `strict`\n\nThis is the default strategy for this platform.\n\nIt aims to comply fully with [Apple's `CFBundleVersion` documentation](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/20001431-102364), which states that the version number should be a string comprised\nof three non-negative, period-separated integers.\n\nSo, it may seem that using the semantic version here would make sense. However,\nthere are additional restrictions applied to this version number in that the\nsecond and third digits can only be two digits long. This could be quite\nrestrictive for projects that do not generate a lot of breaking changes\n(i.e. `v1.100.1` would be invalid).\n\nTherefore, in order to allow as many increments as possible during the lifecycle\nof a project this strategy will auto-increment the `CFBundleVersion` in the\nformat `xxxx.xx.xx`, for example:\n\n- `1000.1.1` > `1000.1.2`\n- `1000.1.99` > `1000.2.1`\n- `1000.99.99` > `1001.1.1`\n\nNote that if your current `CFBundleVersion` is already greater that 9999 then\naccording to the documentation above it is already invalid, as the documentation\nalso states that the first number can only be four digits long. So, in this case\nwe will just keep incrementing it following the pattern described above and\nhopefully Apple won't complain!\n\n#### `increment`\n\nThis strategy behaves the same as the `increment` strategy for Android.\n\n#### `relative`\n\nThis strategy behaves the same as the `relative` strategy for Android.\n\n#### `semantic`\n\nUse the semantic version number directly.\n\n#### `env`\n\nUse the version from environment variable `IOS_BUILD_NUMBER`.\n\n#### `none`\n\nDisable updates of the `CFBundleVersion`.\n\n## Pre-releases\n\nPre-release versions present no major challenges for Android, but iOS again gets\na little more complicated. We provide a versioning strategy that will work for\neach platform, or you can choose to ignore pre-releases entirely for a particular\nplatform by setting `versionStrategy.<platform>.preRelease` to `false`.\n\n**Example (defaults shown)**\n\n```json\n{\n  \"plugins\": [\n    [\"semantic-release-react-native\", {\n      \"versionStrategy\": {\n        \"android\": { \"preRelease\": true },\n        \"ios\": { \"preRelease\": true }\n      }\n    }],\n  ]\n}\n```\n\n### Android\n\nFor Android, it is fine to use pre-release versions such as `1.2.3-beta.1`\nas the `vesionName`, so this is what we do.\n\n### iOS\n\nFor iOS, the [`CFBundleShortVersionString`](https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring) and [`CFBundleVersion`](https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleversion) do not support pre-release versions.\n\nTo get around this limitation for pre-releases we generate a patch version by multiplying\nthe current patch by 10,000 and adding the pre-release version. For example, if the\ncurrent version is `1.1.1` and the next release version is `1.2.2-beta.42`\nresulting iOS version and build number will be `1.1.20042`. This should help\navoid clashes that may otherwise happen if you are pushing pre-releases to TestFlight.\n\nNote that this feature only works when using the `strict` versioning strategy\nfor iOS (which is the default).\n\n## Xcode project files\n\nTo help accommodate projects that use Xcode to manage their versioning this plugin\nwill update the `CURRENT_PROJECT_VERSION` in the same way as the `CFBundleVersion`\nand the `MARKETING_VERSION` in the same was as the `CFBundleShortVersionString`.\nIf these variables are not present in the first place then nothing will be added.\n\nWhether or not you choose to commit these updates is up to you. If you are not\nactually using these variables in your `Info.plist` files then they are probably\nredundant anyway.\n","readmeFilename":"README.md"}