zuntaV2-main

Yarn

Yarn install will require a ${NPM_TOKEN} env variable. To get this variable you can do the following:

• Using the npm Website:
• Go to the npm website and log in to your account.
• Navigate to your account settings or profile.
• Look for a section labeled "Tokens," "Access Tokens," or something similar.
• Click on "Generate New Token" or a similar button.
• Select the type of token you want to create. For read/write access, you'll typically select a token with both read and publish permissions.
• run export the token value. i.e. export NPM_TOKEN=npm_kl9...

You will need permissions in NPM to generate a token that can access Zunta private projects. If you don't have permission ask for it. In the meantime you could get it from CI/CD pipelines in Gitlab

Database setup (local)

Zunta services are configured to run on a zunta_v2 database. If you don't have this databse you should create it, there won't be a conflict with the existing zunta database since this one is named _v2 If this is the first time running zunta main service you should run the following command

yarn migrate:local

This will create all schemas and tables. You can also run teh command whenevr you pull new code from gitlab as there might be new migration scripts

TypeOrm and DB migration scripts

All Typeorm entities are in the @zunta-database-configs shared library but the scripts to create and run migrations are in each service To create a database migration script run the following

yarn migration:create

It will create a migration file in src/migrations. The file should be renamed to something meaningful but keep in mind that we need to keep the first part of the filename in place
i.e 1708550051039-migration could be renamed to 1708550051039-initial-database-setup.ts

The other way to create migration scripts is to first work with the entity classes and then run:

yarn migration:generate

Config files

We are using the NPM config (https://www.npmjs.com/package/config) package to read configs. The way it works is it reads files in the ./config folder with the following sequence

• Default configurations from default.*.
• Custom environment configurations from <NODE_ENV>.*.
• Local overrides from local.*

As of now we are trying to have it so that everyone has a consistent local environment, which means we have local.yaml in git. In order for us to have that in place and still have overrides for other envirnments the env files will have to be local-<NODE_ENV>.yaml. So for example ./config/local-ci.yaml - used in ci pipelines ./config/local-dev.yaml - used in dev ....