This is the FusionAuth Web SDKs monorepo. This repo manages FusionAuth React, Angular, and Vue SDKs.
Each SDK in this repo offers the following APIs:
shouldAutoRefresh
config option or by invoking a function.Install dependencies with yarn install
.
The SDKs share a core package that contains framework agnostic functionality. Building the core package is a step included in the build script for each SDK (for example build:sdk-react
).
You may use the FusionAuth Quickstarts to consume the package and test changes. See React Quickstart, Angular Quickstart, & Vue Quickstart
There is more than one way to test your changes locally, but yalc has served devs of this project well, as long as you are aware of the gotchas.
You may use the yalc-pub:sdk
scripts in the root package.json. For example, yarn yalc-pub:sdk-react
. These build the SDKs and publish to your yalc store so they may be consumed locally.
Here's a potential iteration:
console.log('Hello 👋')
where you know you’ll see it, to confirm your changes have been consumed.)yarn yalc-pub:sdk-angular
yalc add @fusionauth/angular-sdk
If your changes are not being consumed as you expected, consider the following:
node_modules
and removing all previous yalc installations (rm -rf node_modules && yalc remove --all
). Then reinstall dependencies and re-install from yalc. We've found this to provide consistent iterations, whereas yalc push
has proved flakey for developers of this project..angular
or .nuxt
) between iterations.If you decide to use something like yarn link
instead of yalc
, be aware of how your dependencies are being consumed via the symlink. yalc
copies your assets directly, so it's a more realistic representation of the production build than a symlink.
The SDKs provide the following functionality:
The Playwright end-to-end tests verify the proper functionality of several authentication and authorization endpoints in the FA SDK.
Prerequisites
Configuration
The Playwright configuration (playwright.config.ts) includes settings for running tests in parallel, specifying browser environments, and defining the base URL the tests will perform on.
Running the Tests
Prior to running the tests you will want to check the Server Command that is used to start up a local instance of the FA SDK consuming quickstart application. Additionally you will want to note the port number this application will run on.
To run the tests, enter the following command with the FA SDK consuming quickstart application server start command and port number:
SERVER_COMMAND="your-server-start-command" PORT=your-port-number yarn test:e2e
Example: SERVER_COMMAND="npm run start" PORT=9011 yarn test:e2e
Structure
The e2e tests are structured to use the Page Object Model (POM) design pattern. A POM is a design pattern in test automation that creates an object repository for web UI elements found in the pages directory. This makes tests more maintainable and reusable. Example: In common.page.ts, methods for navigation and authentication are defined. Tests import these page objects to perform actions, ensuring that if the UI changes, only the page object needs updating, not all the tests.
We use a monorepo because our SDKs share core functionality, which is contained in the @fusionauth-sdk/core package. This private module is bundled into the distributed SDK packages, allowing us to maintain core logic in a single place.
For React and Vue, our build tool is Vite
.
Angular differs slightly because @angular-devkit/build-angular:ng-packagr
, the builder for Angular libraries, doesn't support bundling dependencies from outside the Angular workspace. Our solution is to copy the core package's src
directory into the Angular workspace without transpiling it, letting Angular's library builder handle it as if it were not an external dependency. This copied directory functions like a dist
: it is git-ignored, and changes should be made in packages/core
. The build process will then consume the updates. See GitHub issue #84 for more details.
The SDKs use GitHub Actions to automate the release process. Each SDK has a publish workflow defined in .github/workflows
.
Steps to create a release:
changes.md
.docs
script in its package.json.main
.This library may periodically receive updates with bug fixes, security patches, tests, code samples, or documentation changes.
These releases may also update dependencies, language engines, and operating systems, as we\'ll follow the deprecation and sunsetting policies of the underlying technologies that the libraries use.
This means that after a dependency (e.g. language, framework, or operating system) is deprecated by its maintainer, this library will also be deprecated by us, and may eventually be updated to use a newer version.