diff --git a/.github/workflows/build-release-zip.yml b/.github/workflows/build-release-zip.yml
new file mode 100644
index 00000000..fb12f47c
--- /dev/null
+++ b/.github/workflows/build-release-zip.yml
@@ -0,0 +1,57 @@
+name: Build release zip
+
+on:
+  workflow_dispatch:
+  push:
+   branches:
+    - trunk
+
+jobs:
+  build:
+    name: Build release zip
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+
+      - name: Cache vendor
+        id: cache-composer
+        uses: actions/cache@v3
+        env:
+          cache-name: cache-vendor
+        with:
+          path: |
+            vendor
+            ~/.composer/cache
+          key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/composer.json') }}
+
+      - name: Cache node_modules
+        id: cache-node-modules
+        uses: actions/cache@v3
+        env:
+          cache-name: cache-node-modules
+        with:
+          path: node_modules
+          key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
+
+      - name: Setup node version and npm cache
+        uses: actions/setup-node@v3
+        with:
+          node-version: 16
+          cache: 'npm'
+
+      - name: Install Node dependencies
+        if: steps.cache-node-modules.outputs.cache-hit != 'true'
+        run: npm install
+
+      - name: Install Composer dependencies
+        if: steps.cache-vendor.outputs.cache-hit != 'true'
+        run: composer install --no-dev
+
+      - name: Build plugin
+        run: |
+          npm run build
+          npm run build:externals
+
+      - name: Generate ZIP file
+        uses: 10up/action-wordpress-plugin-build-zip@stable
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 24472906..6d7a60fd 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -29,15 +29,16 @@ The develop branch is the development branch which means it contains the next ve
 ## Release instructions
 
 1. Branch: Starting from `develop`, cut a release branch named `release/X.Y.Z` for your changes.
-1. Version bump: Bump the version number in `autoshare-for-twitter.php`, `readme.txt`, `package-lock.json`, `package.json`, and `composer.json`(`autoloader-suffix` config option) if it does not already reflect the version being released. In `autoshare-for-twitter.php` update both the plugin "Version:" property and the plugin `AUTOSHARE_FOR_TWITTER_VERSION` constant.
-1. Changelog: Add/update the changelog in `CHANGELOG.md` and `readme.txt`.
-1. Props: update `CREDITS.md` file with any new contributors, confirm maintainers are accurate.
-1. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in `.distignore`.
-1. Readme updates: Make any other readme changes as necessary.  `README.md` is geared toward GitHub and `readme.txt` contains WordPress.org-specific content.  The two are slightly different.
-1. Merge: Make a non-fast-forward merge from your release branch to `develop` (or merge the pull request), then do the same for `develop` into `trunk` (`git checkout trunk && git merge --no-ff develop`). `trunk` contains the stable development version.
-1. Push: Push your `trunk` branch to GitHub (e.g. `git push origin trunk`).
-1. Release: Create a [new release](https://github.com/10up/autoshare-for-twitter/releases/new), naming the tag and the release with the new version number, and targeting the `trunk` branch. Paste the changelog from `CHANGELOG.md` into the body of the release and include a link to the [closed issues on the milestone](https://github.com/10up/autoshare-for-twitter/milestone/#?closed=1).
-1. SVN: Wait for the [GitHub Action](https://github.com/10up/autoshare-for-twitter/actions/workflows/deploy-to-wpdotorg.yml) to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
-1. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/autoshare-for-twitter/. This may take a few minutes.
-1. Close the milestone: Edit the [milestone](https://github.com/10up/autoshare-for-twitter/milestone/#) with release date (in the `Due date (optional)` field) and link to GitHub release (in the `Description` field), then close the milestone.
-1. Punt incomplete items: If any open issues or PRs which were milestoned for `X.Y.Z` do not make it into the release, update their milestone to `X+1.0.0`, `X.Y+1.0`, `X.Y.Z+1`, or `Future Release`
+2. Version bump: Bump the version number in `autoshare-for-twitter.php`, `readme.txt`, `package-lock.json`, `package.json`, and `composer.json`(`autoloader-suffix` config option) if it does not already reflect the version being released. In `autoshare-for-twitter.php` update both the plugin "Version:" property and the plugin `AUTOSHARE_FOR_TWITTER_VERSION` constant.
+3. Changelog: Add/update the changelog in `CHANGELOG.md` and `readme.txt`.
+4. Props: update `CREDITS.md` file with any new contributors, confirm maintainers are accurate.
+5. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in `.distignore`.
+6. Readme updates: Make any other readme changes as necessary.  `README.md` is geared toward GitHub and `readme.txt` contains WordPress.org-specific content.  The two are slightly different.
+7. Merge: Make a non-fast-forward merge from your release branch to `develop` (or merge the pull request), then do the same for `develop` into `trunk` (`git checkout trunk && git merge --no-ff develop`). `trunk` contains the stable development version.
+8. Push: Push your `trunk` branch to GitHub (e.g. `git push origin trunk`).
+9. Test the pre-release ZIP locally by downloading it from the **Build release zip** action artifact to ensure the plugin doesn't break after release.
+10. Release: Create a [new release](https://github.com/10up/autoshare-for-twitter/releases/new), naming the tag and the release with the new version number, and targeting the `trunk` branch. Paste the changelog from `CHANGELOG.md` into the body of the release and include a link to the [closed issues on the milestone](https://github.com/10up/autoshare-for-twitter/milestone/#?closed=1).
+11. SVN: Wait for the [GitHub Action](https://github.com/10up/autoshare-for-twitter/actions/workflows/deploy-to-wpdotorg.yml) to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
+12. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/autoshare-for-twitter/. This may take a few minutes.
+13. Close the milestone: Edit the [milestone](https://github.com/10up/autoshare-for-twitter/milestone/#) with release date (in the `Due date (optional)` field) and link to GitHub release (in the `Description` field), then close the milestone.
+14. Punt incomplete items: If any open issues or PRs which were milestoned for `X.Y.Z` do not make it into the release, update their milestone to `X+1.0.0`, `X.Y+1.0`, `X.Y.Z+1`, or `Future Release`
diff --git a/package.json b/package.json
index 809ebfb8..985073d9 100644
--- a/package.json
+++ b/package.json
@@ -5,7 +5,7 @@
 	"scripts": {
 		"watch": "webpack -w --devtool eval-cheap-module-source-map --output-pathinfo --mode development --config webpack.gutenberg.config.js",
 		"build": "webpack --optimization-minimize --mode production --config webpack.gutenberg.config.js",
-		"build:externals": "webpack src/js/externals/api-fetch.js -o dist/api-fetch.js -p --module-bind js=babel-loader",
+		"build:externals": "webpack ./src/js/externals/api-fetch.js  --output-path dist/ --output-filename api-fetch.js --mode production",
 		"env": "wp-env",
 		"env:start": "wp-env start",
 		"env:stop": "wp-env stop",