Frontend for søknad om sosialhjelp.
NEXT_PUBLIC_DIGISOS_ENV="localhost"
Miljøvariabelen NEXT_PUBLIC_DIGISOS_ENV velger konfigurasjonsprofiler.
Gyldige profiler er "localhost" til lokal utvikling, "mock" til mock-ekstern, "dev-sbs" til dev og "prod-sbs" til prod.
Konfigurasjonsprofiler og feature-toggles utledes fra disse modi i src/lib/config.ts.
Eksempel ihht «Oppsett av lokalt utviklingsmiljø» i digisos-repoet:
cd ../digisos-docker-compose
docker-compose up \
sosialhjelp-mock-alt \
sosialhjelp-mock-alt-api \
sosialhjelp-soknad-api
Vi bruker Github sitt package registry for npm pakker, siden flere av Nav sine pakker kun blir publisert her.
For å kunne kjøre npm install
lokalt må du logge inn mot Github package registry:
- Lag/forny access token med repo og read:packages rettigheter i github ( under developer settings). husk enable sso
- Login på npm med
npm login --auth-type=legacy --scope=@navikt --registry=https://npm.pkg.github.com
og benytt github brukernavn, epost og tokenet du nettopp genererte
npm --include=dev install # Hent avhengigheter
npm run fetch-api # Hent OpenAPI definition for soknad-api fra mock-miljø og lagrer i soknad-api.json
npm run orval # Genererer API-kode
npm run dev # Bygger less og starter dev-server
npm test # Kjør enhetstestene
En snarvei for oppgradering av avhengigheter er:
npm run checkUpdates
Eventuelle unntak (f. eks. når man er låst til en tidligere major) kan konfigureres i .ncurc.js
.
Image bygges vha Github Actions,
- dev: https://github.com/navikt/sosialhjelp-soknad/actions/workflows/build.yml
- prod: https://github.com/navikt/sosialhjelp-soknad/actions/workflows/build_prod_image.yml
Siden appen ikke kjører på nais lengre, se ikke-nais deploy for informasjon om deploy.
Deploy til dev-gcp gjøres via Github Actions, se: https://github.com/navikt/sosialhjelp-soknad/actions/workflows/deploy_dev.yml
Da må appen gå via proxy. Url er https://digisos.ekstern.dev.nav.no/sosialhjelp/soknad
Vi bruker en litt custom Wonderwall-setup for at scope for KS og Husbanken skal være inkludert.
Først, bekreft at en nøkkel eksisterer for kryptering av Wonderwall-sessions i Redis:
# Denne er trygg å kjøre uansett, ettersom den vil feile om secret alt eksisterer
kubectl create secret generic wonderwall-redis --from-literal=WONDERWALL_ENCRYPTION_KEY=$(openssl rand -base64 32)
Deretter, sørg for at en passende IDPorten-klient er provisjonert via NAIS (DIGISOS_ENV er pt. enten prod eller preprod)
kubectl apply -f wonderwall/${DIGISOS_ENV}/idportenclient.yml
Dette vil føre til opprettelsen av en secret med miljøvariabler for IDporten:
IDPORTEN_CLIENT_ID
, IDPORTEN_CLIENT_JWK
, IDPORTEN_ISSUER, IDPORTEN_JWKS_URI
, IDPORTEN_REDIRECT_URI
, IDPORTEN_TOKEN_ENDPOINT
og IDPORTEN_WELL_KNOWN_URL
.
Nå kan Wonderwall provisjoneres:
kubectl apply -f wonderwall/${DIGISOS_ENV}/wonderwall.yml
Notér at i påvente av mer offisiell støtte for ekstra scopes i Wonderwall, er det mulig at wonderwall.yml
kan måtte tilpasses for det aktuelle miljøet (ingress, env/WONDERWALL_INGRESS og accesspolicy/outbound).
Merk også at accesspolicy må settes på innkommende side i frontend.
Når disse ressursene først er opprettet og konfigurert, trengs ingen fornying for senere deploys.
Spørsmål knyttet til koden eller prosjektet kan rettes mot:
Interne henvendelser kan sendes via Slack i kanalen #team_digisos.
Felles dokumentasjon for våre frontend apper
Dette prosjektet bruker formatering av kode med prettier.
Det er lagt inn automatisk formatering av kode med en pre-commit hook.
Detaljer rundt dette ligger i package.json
. Konfigurasjon av prettier ligger i .prettierrc.mjs
.
Dersom du i tillegg ønsker å sette opp formatering av kode i IntelliJ slik at koden blir formatert før du committer kan det gjøres slik:
- Installer Prettier plugin i IntelliJ
- Trykk ⌥⇧⌘P for å formatere kode
- Optional: Sette opp filewatcher og automatisk formatering. Se her
https://prettier.io/docs/en/webstorm.html#running-prettier-on-save-using-file-watcher