Kristaps Fabians Geikins
bde148f286
* wip * some extra fixes * stuff kinda works? * need to figure out mocks * need to figure out mocks * fix db listener * gqlgen fix * minor gqlgen watch adjustment * lint fixes * delete old codegen file * converting migrations to ESM * getModuleDIrectory * vitest sort of works * added back ts-vitest * resolve gql double load * fixing test timeout configs * TSC lint fix * fix automate tests * moar debugging * debugging * more debugging * codegen update * server works * yargs migrated * chore(server): getting rid of global mocks for Server ESM (#5046) * got rid of email mock * got rid of comment mocks * got rid of multi region mocks * got rid of stripe mock * admin override mock updated * removed final mock * fixing import.meta.resolve calls * another import.meta.resolve fix * added requested test * nyc ESM fix * removed unneeded deps + linting * yarn lock forgot to commit * tryna fix flakyness * email capture util fix * sendEmail fix * fix TSX check * sender transporter fix + CR comments * merge main fix * test fixx * circleci fix * gqlgen bigint fix * error formatter fix * more error formatting improvements * esmloader added to Dockerfile * more dockerfile fixes * bg jobs fix
Using CLI
You can run it like so from the server package's root directory: ./bin/cli (or yarn cli)
Use the --help argument to get more info about each command.
Example for running migrations: yarn cli db migrate latest
Using CLI in test mode (& DB)
Use yarn cli:test to run the CLI in the TEST environment. This will use the test DB and will likely run some code a bit differently than in prod/dev.
Creating new commands
CLI is defined using yargs.We use it to define hierarchical trees of commands which allows for better organization both for command definition and for using the CLI.
All commands are created in the commands directory. Commands should be defined using command modules.
Any top-level modules under commands will be assumed to be command modules. If you want to define a child command for a top-level command, then configure the top-level command to look for further child commands using .commandDir().
Then put those child command modules in a subdirectory that is named after the top level command. So if the top level command is "db", then all of its child commands should be put inside a "db" subfolder.
Example commands dir:
- commands
- db
- migrate.js
- db.js
In this case, db.js is the command module for the top-level db command. And then inside the db folder there's a command module migrate.js for the migrate child command of db.
This results in 2 commands - db and db migrate.