This template should help get you started developing with Vue 3 in Vite.

VSCode + Volar (and disable Vetur).

TypeScript cannot handle type information for .vue imports by default, so we replace the tsc CLI with vue-tsc for type checking. In editors, we need Volar to make the TypeScript language service aware of .vue types.

See Vite Configuration Reference.

Many aspects of this project are highly dependent on the subdomain. Perhaps most importantly, the difference between the student and admin versions of the site is largely determined by whether the user is visiting the pep subdomain or the admin.pep subdomain.

In some browsers, including Chrome and Firefox, it is possible to simply use http://pep.localhost:5173/ and http://admin.pep.localhost:5173/ as the domains for the site. This requires a modification of /etc/hosts and will not work in Safari.

Specifically, a line like the following can be added to /etc/hosts, which will allow browsers to use the subdomains properly:

127.0.0.1 pep.localhost admin.pep.localhost

The .env.example file includes some values and notes that may be useful to place into a .env file. Note that when using a remote server for the API_URL, this will affect the application's environment. The prod API will use production data and return prod in the environment check that determines the URL of the login button.

Install nvm for managing the project node version.

Activate the pinned node version based on this project's .nvmrc file.

$ nvm use

If you do not have that node version on your local machine, nvm will say so. Use nvm install to install the pinned version.

Finally, install project depdendencies:

$ yarn install

yarn dev

yarn build

yarn test:unit:dev # or `yarn test:unit` for headless testing

yarn test:e2e:dev

This runs the end-to-end tests against the Vite development server. It is much faster than the production build.

But it's still recommended to test the production build with test:e2e before deploying (e.g. in CI environments):

yarn build
yarn test:e2e

yarn lint

Logs are sent from the frontend to the backend using the Beacon API in order to send non-blocking requests to the server. Log events must include and eventtype and event_description. The remaining fields necessary for Captain's Logging will be added by the backend. Additional fields can be added as needed.

Frontend logging works locally as well as in the TEST and PROD environments. In the ephemeral cluster, however, it will return 405 Method Not Allowed errors as a result of CORS issues. This does mean frontend logs will not work in the ephemeral environment.

The first time you run the docker image build locally, first run:

cp nginx/nginx.conf.persistent nginx/nginx.conf

This simulates the repo setup that takes place during the build app image job in our CICD setup.