twine-app v0.9.2

Twine App

The Twine App is started by using Vite, can read more about it here & see included README.md at the bottom.

Getting Started

To get started you'll need:

• node >= 16.x
• vite cli

To install Vite you can run the following command:

npm install -g vite@latest

If using VSCode, we recommend installing the Vetur extension and enabling the following setting vetur.experimental.templateInterpolationService.

Once setup run

npm install

To start the development server on port 3000 run

npm run dev -- --port 3000

Or

npx vite --port 3000

Access to the Shared Components Feed

Follow the instructions a https://dev.azure.com/xpressfeeders/Sagarmatha/_artifacts/feed/Sagarmatha-Shared-Library/connect/npm

Repo Structure & Branching Strategy

Twine currently has two long living branches main and prod. Both of these are protected branch and can only be updated using the Pull Request (PR) process.

Current branching strategy used is a variation of GitFlow, which use the following convensions.

• main - Active development branch, hold all the latest developed features
• feature/*name* or bugfix/*name* - Feature or Bugfix currently in development, the prefix of feature/ or bugfix/ is currently optional.
• hotfix/*name* - Fix for a high priority bug in production. This should only ever be merged into the prod branch.
• prod - Current code running in our Production environment. This branch would be the base for any hotfixes.
• release/*name* - The next planned release to production. This should be the code running in the UAT environment, when no hotfixes are active

Note: Both release/* and prod branches should be back merged into the main branch to ensure fixes in each aren't lost.

For release/* this should happen when once the release is promoted to prod

For prod this should happen when a hotfix is released

Deployments

• main will be deployed to the Dev environment after every successful CI build, and can be optionally deployed to the UAT environment if needed.
• release/* will be deployed to the UAT environment
• prod currently still follows a manual deployment process

Running SonarQube Scanner

Note: We are looking into moving to SonarCloud in the near future. Which should prevent the need to port forward to K8s Pods

To run SonarQube Scanner locally, you first need to install the sonar-scanner CLI tools.

Option 1:

Download for sonarqube documentation and follow their instructions. SonarQube Docs

Option 2:

Install using choco or brew

# MacOS
brew install sonar-scanner  
# Windows
choco install sonarqube-scanner.portable

Once installed you'll need to expose the container in Kube to your local machine.

export POD_NAME=$(kubectl get pods --namespace sonarqube -l "app=sonarqube,release=sonarqube" -o jsonpath="{.items[0].metadata.name}")
echo "Visit http://127.0.0.1:8080 to use your application"
kubectl port-forward $POD_NAME 8080:9000 -n sonarqube

Once the port forwarding has been setup up run sonar-scanner from the root directory of the repository

sonar-scanner -Dsonar.login=c8b8d659ea31dfa74f3abea3e8acdbb02ab47090 -Dsonar.host.url=http://localhost:8080/sonarqube

Manual Deployments

This project currently has a CI/CD pipeline that will deploy all changes in the main, but in the case that the pipeline is down.

npm run build

Note: Current command assume production builds, later changes will include builds for UAT and PROD as two commands

For Linux/Mac

./manual-deploy.sh -a *StorageAccountName*

For Windows

./manual-deploy.ps1 -a *StorageAccountName*

From Vite template…

Vue 3 + Typescript + Vite

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

Recommended IDE Setup

VSCode + Vetur. Make sure to enable vetur.experimental.templateInterpolationService in settings!

If Using <script setup>

<script setup> is a feature that is currently in RFC stage. To get proper IDE support for the syntax, use Volar instead of Vetur (and disable Vetur).

Type Support For .vue Imports in TS

Since TypeScript cannot handle type information for .vue imports, they are shimmed to be a generic Vue component type by default. In most cases this is fine if you don't really care about component prop types outside of templates. However, if you wish to get actual prop types in .vue imports (for example to get props validation when using manual h(...) calls), you can use the following:

If Using Volar

Run Volar: Switch TS Plugin on/off from VSCode command palette.

If Using Vetur

1. Install and add @vuedx/typescript-plugin-vue to the plugins section in tsconfig.json
2. Delete src/shims-vue.d.ts as it is no longer needed to provide module info to Typescript
3. Open src/main.ts in VSCode
4. Open the VSCode command palette
5. Search and run "Select TypeScript version" -> "Use workspace version"