Transition Pathways Repository (TPR)

1. Clone the Repo

git clone https://github.com/RMI/tpr
cd tpr

2. Create an .env file to store the desired frontend port

cp env.example .env

3. Run the service

npm run dev

The application is deployed using Azure Static Web Apps:

• Production: View Production Site
  Deployed automatically when changes are merged to the production branch

• Development: View Development Site
  Reflects the current state of the main branch

Pull requests automatically deploy to preview environments with URLs provided in the PR comments.

This project uses Node.js and npm for dependency management.

To install Node.js, follow the official installation guide.

1. Install Dependencies

cd tpr
npm install

2. Running the Frontend You can locally serve the frontend alone with:

npm run dev

The local development service will be accessible at http://localhost:3000. It automatically reloads on file changes.

3. Building the application To render the site,

npm run build
# or for a PROD BUILD
VITE_BUILD_MODE=production npm run build

Then you can serve the dist/ directory using your favorite local server. For example, to use python's server,

python3 -m http.server 9001 -d ./dist

Dependencies are managed using npm. To add a new library, run:

npm install <library> # for runtime dependencies
npm install --save-dev <library> # for development dependencies

This project uses Vitest for unit testing. To run the tests, use:

npm run test

This project uses ESLint and Prettier for code consistency:

# Check code for issues
npm run lint
# Fix linting issues automatically
npm run lint:fix
# Format code with Prettier
npm run format

This project uses semantic-release to manage release versions. See "Releases" on the right of the main GitHub repository page to see the latest released version, or click through to see pre-releases.

To trigger an update in released version, use Conventional Commits in your normal development process. Commits with a feat prefix (in the commit summary) will cause a bump in the minor version (x.X.x), while a fix, build, docs, perf, refactor, style, or test prefix will bump the patch version (x.x.X). The commit summary used will appear in the release notes.

The "released" version of the application is updated when the production branch is updated, but we can see pre-release versions by updating main (updates x.x.x-dev.y) or next (updates x.x.x-rc.y). When opening a Pull Request, an GitHub workflow will dry-run the release process and comment with a preview of the expected version tag and release notes.

At the moment, schemata are for internal use only and are treated as malleable. We do not consider a minor schema change a breaking change for external users at the moment. This is subject to change, once the use of the transition pathways repository requires it, e.g. once it has external consumers.

This project is licensed under the MIT License