The frontend of https://saddlebagexchange.com/
Last updated for FFXIV 6.51
Frontend for Aetheryte API
- Node
20.3.0
- Discord Application (for OAuth functionality)
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
nvm install 20
nvm use 20
Install the dependencies:
yarn install
Run Server:
yarn run dev
For Windows:
yarn dev
This starts your app in development mode, rebuilding assets on file changes.
Check your terminal for the address, the default is http://127.0.0.1:8788
To enable Discord login functionality, you need to set up a Discord application:
- Go to the Discord Developer Portal
- Create a new application
- Go to the "OAuth2" section
- Add your redirect URI:
http://localhost:8788/discord-callback
(for development) - Copy your Client ID and Client Secret
- Set the following environment variables:
DISCORD_CLIENT_ID
: Your Discord application client IDDISCORD_CLIENT_SECRET
: Your Discord application client secretDISCORD_BOT_TOKEN
: Your Discord bot token for pulling role ids
For production, update the redirect URI to your production domain.
You can fetch and update the ffxiv items list if you find items are missing using:
yarn run write-items
prettier -w app/utils/items/items.ts
We have just started to use Vitest to run unit tests.
We are currently using the .test.ts ending to mark our test files for the test runner.
For any route level testing, such as action files or loaders keep your test files in the app/test/routes
folder.
For other files try to keep your test files in the same folder as the file your testing. If this gets out of hand we can try to manage the test files into the test folder too. We'll see how it goes.
You can run all unit tests by running:
yarn test
You can run a single unit test file by running
yarn test testFile
You can set vite into watch mode by passing the watch arguement:
yarn test watch
Commit to master
. Auto deploys to CloudFlare.
https://dash.cloudflare.com/131d3ef77f51b43d39c70f2e5b65c34c/pages/view/saddlebag-with-pockets
For those interested, we're using the following in the front-end architecture:
Can always upgrade some packages easily without breaking anything. These are handled with:
./low-impact-package-upgrade.sh