Publish 0.12.0 release notes (#536)

* fix: (#500) setting appropriate faust links from the plugin (#501)

* make: (#504) release `0.6.1` (#505)

* chore: update package-lock.json for 0.11.0 (#506)

* Use `.env.local` instead of `.env` (#512)

* Use `.env.local` instead of `.env`

* Exclude `.env.local.sample` from gitignore

* fix: (#503) remove refresh token logic (#507)

Remove the existing refresh token upon an unauthorized response from the fetch token endpoint

* Implement changesets (#521)

* Implement changesets

* Update changesets config

* Release faust packages in lockstep

* changeset commands

* Create version:status command

* Create release packages action

* Update contributing guide

* Include changeset to kick off PR

* Remove old version script

* Fix node version in release packages action (#522)

* Implement `logoutHandler` middleware (#525)

* Implment `logoutHandler` middleware

* Create changeset

* chore: include gqty as a monorepo dev dependency (#527)

* Add option to disable redirect in `useAuth` hook when a user is unauthenticated (#531)

* Add option to disable redirect in `useAuth` hook

Introduced `UseAuthOptions` that allows a user to specify the `shouldRedirect` property. This property defines if the `useAuth` hook should redirect to the appropriate url when unauthenticated.

* `UseAuthOptions` docs

Describe the new `UseAuthOptions` properties and provide examples

* `UseAuthOptions` changeset

* Changeset for `Content-Type` header fix

* Fix middleware tests

Added `setHeader` to res mock

* Use lodash defaults for `UseAuthOptions`

* e2e test improvements (#530)

* chore: avoid using default mysql port on host machine

* chore: update broken test

* chore: update broken preview test

* chore: update e2e test instructions

* docs: formatting and wording updates

* docs: .env.test.local -> .env.test

* Feat isr timing (#520)

* feat: (#516) adding a next config, moving nextConfig to withFaust

* fix: removing try/catch from getProps and adding beforeEach to getProps.test for creating config

* feat: (#516) configuration is separate per package

* feat: (#516) updating tests, docs, exports, and examples to use config instead of headlessConfig

* doc: (#516) adding changeset for ISR timing configuration

* Introduce `apiRouter` to handle Faust.js API endpoints (#532)

* Create API Router node handler for api middleware

Removed the `apiEndpoint` config option in exchange for `apiBasePath`. Additionally, the `pages/api/auth/wpe-headless.ts` file was deleted in exchange for the API route, `pages/api/faust/[[...route]].ts`

* Rename `faustApiRouter` to `apiRouter`

* Update preview docs to use `apiRouter`

* Import Faust API endpoint partials from config

* Do not expose the makeup of the Faust API  on 404

* feat: (#533) separating server and client exports, dynamically importing server code where necessary

* Use `headlessConfig` -> `config`

* Remove old params from `config()`

Co-authored-by: William Johnston <will@wwj.dev>

* Version Packages (#523)

Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

* Fix remove old publish script (#534)

* Remove old publish script

* Remove package-lock on release

* Remove package-lock.json in all actions

* Release Notes for 0.12.0 (#535)

* Authentication Docs (#484)

* WIP: Auth docs

* docs: auth strategies

* docs: auth hooks

* docs: misc auth fixes

* docs: making auth requests

* docs: auth final touches

* docs: update auth page desc

* Add pr to `0.11.0` release notes

* Update release notes for 0.12.0

* Make 0.12.0 breaking changes more clear

* make breaking changes clearer in 0.12.0

Co-authored-by: William Johnston <will@wwj.dev>

Co-authored-by: Will Johnston <wjohnsto@users.noreply.github.com>
Co-authored-by: Andrew Matthews <andrew.matthews@wpengine.com>
Co-authored-by: William Johnston <will@wwj.dev>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

.changeset/config.json

@@ -0,0 +1,12 @@
+{
+  "$schema": "https://unpkg.com/@changesets/config@1.6.1/schema.json",
+  "changelog": "@changesets/cli/changelog",
+  "commit": false,
+  "linked": [
+    ["@faustjs/core", "@faustjs/next", "@faustjs/react"]
+  ],
+  "access": "public",
+  "baseBranch": "canary",
+  "updateInternalDependencies": "patch",
+  "ignore": ["next-headless-getting-started"]
+}

.github/workflows/e2e-next-example.yml

@@ -31,6 +31,7 @@ jobs:
     - name: install and build packages
       working-directory: ./
       run: |
+        rm package-lock.json
         npm install
         npm run build
     # To ensure PR changes are tested accurately, we replace the 
@@ -47,7 +48,7 @@ jobs:
     - name: copy env
       working-directory: e2e-app
       run: |
-        cp .env.sample .env
+        cp .env.local.sample .env.local
     # Generate the schema to ensure no type collisions
     - name: Generate Schema
       working-directory: e2e-app

.github/workflows/eslint.yml

@@ -8,6 +8,7 @@ jobs:
       - uses: actions/setup-node@v2
         with:
           node-version: '16'
+      - run: rm package-lock.json
       - run: npm install
       - run: npm run build
       - run: npm run lint

.github/workflows/release-packages.yml

@@ -0,0 +1,47 @@
+name: Release Packages
+
+on:
+  push:
+    branches:
+      - canary
+
+jobs:
+  release_packages:
+    name: Release Packages
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout Repo
+        uses: actions/checkout@master
+        with:
+          # This makes Actions fetch all Git history so that Changesets can generate changelogs with the correct commits
+          fetch-depth: 0
+
+      - name: Setup Node.js 16.x
+        uses: actions/setup-node@master
+        with:
+          node-version: 16.x
+
+      - name: Remove package-lock.json
+        run: |
+          rm package-lock.json
+
+      - name: Install Dependencies
+        run: npm install
+
+      - name: Create .npmrc
+        run: |
+          cat << EOF > "$HOME/.npmrc"
+            //registry.npmjs.org/:_authToken=$NPM_TOKEN
+          EOF
+        env:
+          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
+
+      - name: Create Release Pull Request or Publish to npm
+        id: changesets
+        uses: changesets/action@master
+        with:
+          # This expects you to have a script called release which does a build for your packages and calls changeset publish
+          publish: npm run release
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

.github/workflows/test.yml

@@ -8,6 +8,7 @@ jobs:
       - uses: actions/setup-node@v2
         with:
           node-version: '16'
+      - run: rm package-lock.json
       - run: npm install
       - run: npm run build
       - run: npm test

.gitignore

@@ -8,6 +8,6 @@ process.yml
 .next
 .env
 .env.*
-!.env.sample
+!.env.local.sample
 .docusaurus
 build/

CONTRIBUTING.md

@@ -5,31 +5,32 @@
 [Search the existing issues](https://github.com/wpengine/faustjs/search?type=Issues) before logging a new one.
 
 Some search tips:
-* *Don't* restrict your search to only open issues. An issue with a title similar to yours may have been closed as a duplicate of one with a less-findable title.
-* Search for the title of the issue you're about to log. This sounds obvious but 80% of the time this is sufficient to find a duplicate when one exists.
-* Read more than the first page of results. Many bugs here use the same words so relevancy sorting is not particularly strong.
-* If you have a crash, search for the first few topmost function names shown in the call stack.
+
+- _Don't_ restrict your search to only open issues. An issue with a title similar to yours may have been closed as a duplicate of one with a less-findable title.
+- Search for the title of the issue you're about to log. This sounds obvious but 80% of the time this is sufficient to find a duplicate when one exists.
+- Read more than the first page of results. Many bugs here use the same words so relevancy sorting is not particularly strong.
+- If you have a crash, search for the first few topmost function names shown in the call stack.
 
 ## 2. Did You Find A Bug?
 
 When logging a bug, please be sure to include the following:
 
-* What version of the package/plugin are you using
-* If at all possible, an *isolated* way to reproduce the behavior
-* The behavior you expect to see, and the actual behavior
+- What version of the package/plugin are you using
+- If at all possible, an _isolated_ way to reproduce the behavior
+- The behavior you expect to see, and the actual behavior
 
 ## 3. Do You Have A Suggestion?
 
 We also accept suggestions in the issue tracker. Be sure to [search](https://github.com/wpengine/faustjs/search?type=Issues) first.
 
-
 In general, things we find useful when reviewing suggestions are:
-* A description of the problem you're trying to solve
-* An overview of the suggested solution
-* Examples of how the suggestion would work in various places
-  * Code examples showing e.g. "this would be an error, this wouldn't"
-  * Code examples showing usage (if possible)
-* If relevant, precedent in other frameworks or libraries can be useful for establishing context and expected behavior
+
+- A description of the problem you're trying to solve
+- An overview of the suggested solution
+- Examples of how the suggestion would work in various places
+  - Code examples showing e.g. "this would be an error, this wouldn't"
+  - Code examples showing usage (if possible)
+- If relevant, precedent in other frameworks or libraries can be useful for establishing context and expected behavior
 
 # Instructions For Contributing Code
 
@@ -38,19 +39,20 @@ In general, things we find useful when reviewing suggestions are:
 0. [A bug or feature you want to work on](https://github.com/wpengine/faustjs/labels/help%20wanted)! If you have found a new bug or want to propose a feature, please [create an issue](https://github.com/wpengine/faustjs/issues/new/choose) before starting a pull request.
 1. [A GitHub account](https://github.com/join).
 2. A working copy of the code. See [DEVELOPMENT.md](/DEVELOPMENT.md).
+3. A `changeset` that describes the changes you're making. You can create a `changeset` by running `npm run changeset` from the monorepo root.
 
 ## Housekeeping
 
 Your pull request should:
 
-* Include a description of what your change intends to do
-* Reference any open issues that the PR addresses
-* Be based on reasonably recent commit in the **canary** branch
-* Include adequate tests
-    * At least one test should fail in the absence of your non-test code changes. If your PR does not match this criteria, please specify why
-    * Tests should include reasonable permutations of the target fix/change
-    * Include baseline changes with your change
-* Contain proper [semantic commit messages](https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716#gistcomment-3711094) as follows:
+- Include a description of what your change intends to do
+- Reference any open issues that the PR addresses
+- Be based on reasonably recent commit in the **canary** branch
+- Include adequate tests
+  - At least one test should fail in the absence of your non-test code changes. If your PR does not match this criteria, please specify why
+  - Tests should include reasonable permutations of the target fix/change
+  - Include baseline changes with your change
+- Contain proper [semantic commit messages](https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716#gistcomment-3711094) as follows:
 
   ```
     <type>[<scope>]: (<issue #>) <short summary>
@@ -64,4 +66,4 @@ Your pull request should:
       └─> Type: chore, docs, feat, fix, refactor, style, or test.
   ```
 
-* To avoid line ending issues, set `autocrlf = input` and `whitespace = cr-at-eol` in your git configuration
+- To avoid line ending issues, set `autocrlf = input` and `whitespace = cr-at-eol` in your git configuration

DEVELOPMENT.md

@@ -2,10 +2,10 @@
 
 There are many ways to [contribute](/CONTRIBUTING.md) to this project.
 
-* [Discuss open issues](https://github.com/wpengine/faustjs/issues) to help define the future of the project.
-* [Submit bugs](https://github.com/wpengine/faustjs/issues) and help us verify fixes as they are checked in.
-* Review and discuss the [source code changes](https://github.com/wpengine/faustjs/pulls).
-* [Contribute bug fixes](/CONTRIBUTING.md)
+- [Discuss open issues](https://github.com/wpengine/faustjs/issues) to help define the future of the project.
+- [Submit bugs](https://github.com/wpengine/faustjs/issues) and help us verify fixes as they are checked in.
+- Review and discuss the [source code changes](https://github.com/wpengine/faustjs/pulls).
+- [Contribute bug fixes](/CONTRIBUTING.md)
 
 ## Project Structure
 
@@ -28,8 +28,7 @@ When switching git branch, run `npm run clean` from the root and then re-run `np
 
 As this is a monorepo, you will not be able to check out this repository into `wp-content/themes` or `wp-content/plugins`.
 
-Instead, you can create symlinks to the themes/plugins in this repository. Best of all, this will also sync your work
-across multiple local sites!
+Instead, you can create symlinks to the themes/plugins in this repository. Best of all, this will also sync your work across multiple local sites!
 
 #### WPE Headless Plugin
 
@@ -44,11 +43,13 @@ ln -s /path/to/faustjs/plugins/wpe-headless /path/to/wordpress/wp-content/plugin
 [PHP Code Sniffer](https://github.com/squizlabs/PHP_CodeSniffer) is configured for the [WordPress code standards](https://make.wordpress.org/core/handbook/best-practices/coding-standards/).
 
 Install the composer packages from within `wpe-headless` directory if you haven't already.
+
 ```
 composer install
 ```
 
 Run the syntax check.
+
 ```
 composer phpcs
 ```
@@ -67,11 +68,13 @@ To run WordPress unit tests, set up the test framework:
 ```
 
 If you connect to MySQL via a sock connection, you can run the following.
+
 ```
 /bin/bash /path/to/faustjs/plugins/wpe-headless/tests/install-wp-tests.sh wpe_headless_tests db_name db_password localhost:/path/to/mysql/mysqld.sock
 ```
 
 Install the composer packages from within `wpe-headless` directory if you haven't already.
+
 ```
 composer install
 ```
@@ -94,34 +97,42 @@ Use [Codeception](https://codeception.com/) for running end-2-end tests in the b
 
 ### 1. Environment Setup
 
+1. Install [Docker](https://www.docker.com/get-started).
 1. Install [Composer](https://getcomposer.org/).
-    - Within the `plugins/wpe-headless` directory, run `composer install`.
 1. Install [Google Chrome](https://www.google.com/chrome/).
 1. Install [Chromedriver](https://chromedriver.chromium.org/downloads)
-    - The major version will need to match your Google Chrome [version](https://www.whatismybrowser.com/detect/what-version-of-chrome-do-i-have). See [Chromedriver Version Selection](https://chromedriver.chromium.org/downloads/version-selection).
-    - Unzip the chromedriver zip file and move `chromedriver` application into the `/usr/local/bin` directory.
-      `mv chromedriver /usr/local/bin`
-    - In shell, run `chromedriver --version`. _Note: If you are using OS X, it may prevent this program from opening. Open "Security & Privacy" and allow chromedriver_.
-    - Run `chromedriver --version` again. _Note: On OS X, you may be prompted for a final time, click "Open"_. When you can see the version, chromedriver is ready.
+   - The major version will need to match your Google Chrome [version](https://www.whatismybrowser.com/detect/what-version-of-chrome-do-i-have). See [Chromedriver Version Selection](https://chromedriver.chromium.org/downloads/version-selection).
+   - Unzip the chromedriver zip file and move `chromedriver` application into the `/usr/local/bin` directory.
+     `mv chromedriver /usr/local/bin`
+   - In shell, run `chromedriver --version`. _Note: If you are using OS X, it may prevent this program from opening. Open "Security & Privacy" and allow chromedriver_.
+   - Run `chromedriver --version` again. _Note: On OS X, you may be prompted for a final time, click "Open"_. When you can see the version, chromedriver is ready.
+
+### 2. Front-end Setup
 
-### 2. Headless Site Setup
-1. From within the headless site `examples/getting-started` copy `.env.test.sample` to `.env.test`.
-    - If you are using the provided Docker build, you will not need to adjust any variables in the `.env.testing` file; else, you can adjust the environment variables as needed.
+1. Create the following `.env.test` in `examples/next/getting-started`.
+```
+# Your WordPress site URL
+NEXT_PUBLIC_WORDPRESS_URL=http://localhost:8080
+
+# Plugin secret found in WordPress Settings->Headless
+WP_HEADLESS_SECRET=00000000-0000-0000-0000-000000000001
+```
+2. From within `examples/next/getting-started`, run `NODE_ENV=test npm run dev`.
 
-### 3. WPE Headless Setup
+### 3. WordPress Setup
+
+1. Leave the node server running and open a new shell.
 1. Move into the WPE Headless plugin directory `plugins/wpe-headless`.
+1. Run `composer install` if you haven't already.
 1. Prepare a test WordPress site.
-    - We have provided a Docker build to reduce the setup needed. You are welcome to set up your own WordPress end-2-end testing site.
-      1. Install [Docker](https://www.docker.com/get-started).
-      1. Run `docker-compose up -d --build`. If building for the first time, it could take some time to download and build the images.
-      1. Run `docker-compose exec --workdir=/var/www/html/wp-content/plugins/wpe-headless --user=www-data wordpress wp plugin install wp-graphql --activate`
-      1. Run `docker-compose exec --workdir=/var/www/html/wp-content/plugins/wpe-headless --user=www-data wordpress wp db export tests/_data/dump.sql`
+    1. Run `docker-compose up -d --build`. If building for the first time, it could take some time to download and build the images.
+    1. Run `docker-compose exec --workdir=/var/www/html/wp-content/plugins/wpe-headless --user=www-data wordpress wp plugin install wp-graphql --activate`
+    1. Run `docker-compose exec --workdir=/var/www/html/wp-content/plugins/wpe-headless --user=www-data wordpress wp db export tests/_data/dump.sql`
 1. Copy `.env.testing.example` to `.env.testing`.
-    - If you are using the provided Docker build, you will not need to adjust any variables in the `.env.testing` file.
-    - If you are not using the provided Docker build, edit the `.env.testing` file with your test WordPress site information.
 1. Run `vendor/bin/codecept run acceptance` to start the end-2-end tests.
 
 ### Browser testing documentation
+
 - [Codeception Acceptance Tests](https://codeception.com/docs/03-AcceptanceTests)
   - Base framework for browser testing in php.
 - [WPBrowser](https://wpbrowser.wptestkit.dev/)
@@ -154,6 +165,6 @@ CircleCI will build and deploy the plugin zip. The latest version will be availa
 
 Once deployed, the updated packages will be visible here:
 
-* https://www.npmjs.com/package/@faustjs/core
-* https://www.npmjs.com/package/@faustjs/react
-* https://www.npmjs.com/package/@faustjs/next
+- https://www.npmjs.com/package/@faustjs/core
+- https://www.npmjs.com/package/@faustjs/react
+- https://www.npmjs.com/package/@faustjs/next

docs/next/getting-started.mdx

@@ -35,7 +35,7 @@ npx create-next-app `
 Now, copy the sample environment template:
 
 ```bash
-cp .env.sample .env
+cp .env.local.sample .env.local
 ```
 
 Finally, run the dev server:
@@ -65,7 +65,7 @@ The example app above loads WordPress content from the demo site at [https://hea
 
 To point it to a different WordPress site, first, [make sure you have setup the necessary WordPress plugins.](../tutorial/setup-faustjs#installing-plugins-on-wordpress)
 
-Once the necessary plugins have been installed, open the `.env` file you created earlier, it should look something like this:
+Once the necessary plugins have been installed, open the `.env.local` file you created earlier, it should look something like this:
 
 ```bash
 # Your WordPress site URL