|
| 1 | +# Production workflow |
| 2 | + |
| 3 | +The following steps describe the intended release process and optional services to use (e.g. Travis). |
| 4 | + |
| 5 | + |
| 6 | +## Handle extension version |
| 7 | + |
| 8 | +If you take a look to your `src/manifest.json`, you will see that `version` is `null`. |
| 9 | + |
| 10 | +When building, it injects the version of your `package.json` in your `src/manifest.json`. That means you should not update `manifest.json`'s directly. |
| 11 | + |
| 12 | +By doing this, it means that you could use one of the following commands to easily update your version: |
| 13 | + |
| 14 | +```bash |
| 15 | +npm version major # 1.x.x -> 2.x.x, when you release a breaking change |
| 16 | +npm version minor # x.1.x -> x.2.x, when you release a feature |
| 17 | +npm version patch # x.x.1 -> x.x.2, when you release a patch |
| 18 | +npm version 1.2.3 # custom version |
| 19 | + |
| 20 | +# for yarn: |
| 21 | +yarn version --major |
| 22 | +yarn version --minor |
| 23 | +yarn version --patch |
| 24 | +yarn version --new-version 1.2.3 |
| 25 | +``` |
| 26 | + |
| 27 | +::: tip Tips |
| 28 | +1. It is recommended to follow [Sementic Versioning](https://semver.org/) rules! |
| 29 | +2. Using `npm version` or `yarn version` will create update your `package.json`, create a new commit and a new tag, this is really helpful! |
| 30 | +::: |
| 31 | + |
| 32 | + |
| 33 | +## Building for production |
| 34 | + |
| 35 | +Once you have updated your version, you can run: |
| 36 | + |
| 37 | +```bash |
| 38 | +npm run build |
| 39 | +npm run build-zip |
| 40 | + |
| 41 | +# for yarn: |
| 42 | +yarn build |
| 43 | +yarn build-zip |
| 44 | +``` |
| 45 | + |
| 46 | +Those commands will: |
| 47 | + |
| 48 | +- build your extension for production (and use your `package.json` version for your `manifest.json`), located in `dist/` |
| 49 | +- build a `.zip`, located in `dist/zip/<your-extension-name>-<version>.zip` |
| 50 | + |
| 51 | +When publishing on the [Chrome Web Store](https://chrome.google.com/webstore) (or [Firefox Add-ons](https://addons.mozilla.org)), you should upload your fresh `.zip`! |
| 52 | + |
| 53 | + |
| 54 | +## Automatic build and release with Travis |
| 55 | + |
| 56 | +If you are using [Travis](https://travis-ci.com/), you can setup [GitHub Releases upload](https://docs.travis-ci.com/user/deployment/releases/) in order to automatically build a zip of your extension and attach it to your GitHub releases ([example](https://github.com/Kocal-Web-Extensions/Solary/releases/tag/v1.9.0)): |
| 57 | + |
| 58 | +```yaml |
| 59 | +script: |
| 60 | + - yarn build |
| 61 | + - yarn build-zip |
| 62 | + |
| 63 | +before_deploy: |
| 64 | + - export RELEASE_EXTENSION_FILE=$(ls dist-zip/*.zip) |
| 65 | + - echo "Deploying ${RELEASE_EXTENSION_FILE} to GitHub releases" |
| 66 | + |
| 67 | +deploy: |
| 68 | + provider: releases |
| 69 | + api_key: |
| 70 | + secure: <YOUR API KEY> |
| 71 | + file: '${RELEASE_EXTENSION_FILE}' |
| 72 | + skip_cleanup: true # To keep, otherwise your `.zip` will be cleaned |
| 73 | + on: |
| 74 | + repo: <YOUR REPO> |
| 75 | + tags: true # Only on a new git tag |
| 76 | +``` |
| 77 | +
|
| 78 | +This is really useful if you don't want to manually run commands from [Building for production](https://vue-web-extension.netlify.app/intro/production-workflow#building-for-production). |
0 commit comments