You will need to install the project's npm dependencies:
npm install # this will install dependencies for both packages (cli and create-cli)
To run a build with TS for type checking, run:
npm run prepare --workspace packages/create-cli
When running commands from the packages/create-cli
directory, the --workspace packages/create-cli
flag isn't necessary.
Use CHECKLY_CLI_VERSION
environment variable to set the latest version you want to test.
You can configure the stage (production
, staging
, development
or local
) using CHECKLY_ENV
environment variable. Use CHECKLY_ENV=local
if you want to point the API URL to your local backend http://localhost:3000
.
Also, you can use the watch
mode to compile during your coding. You can use the following command to start your local environment:
export CHECKLY_ACCOUNT_ID=<YOUR_LOCAL_BACKEND_ACCOUNTID>
export CHECKLY_API_KEY=<YOUR_LOCAL_BACKEND_API_KEY>
export CHECKLY_ENV=local
npm run watch --workspace packages/cli
To run the E2E tests pointing to your local backend use the npm run test:e2e:local --workspace packages/cli
Remember that the --workspace packages/cli
flag isn't necessary when running commands from the packages/cli
directory.
You can use any branch of the code and npm link
it so you can use the latest version in any other repo / project as if
you are using the installed NPM package
- Go to the packages
./packages/cli
and./packages/create-cli
directories and runnpm link
- Go to your other project and run
npm link checkly
andnpm link create-checkly
Make sure you are on the same NodeJS version if you are using nvm
or fnm
You can use the current branch of the code against any examples in the /examples
directory for developing and debugging.
- Go the
~/your_local_path
directory. - Run
npm create checkly -- --template boilerplate-project
- Just use
npx checkly
as normal.
To publish a NPM package for testing purpose, you can tag the pull-request with the build
label. A GitHub Action will be
triggered and a new experimental version can be installed by executing:
npm install checkly@0.0.0-pr.<PR-NUMBER>.<COMMIT_SHORT_SHA>
Both packages checkly and create-cli are built and published by the corresponding GitHub action here.
To release packages to NPM:
- Publish a Github Release with a valid tag
#.#.#
and click theGenerate release notes
button to auto-generate notes following format defined here - When release is published the Github action is triggered. It builds and publishes
#.#.#-prerelease
prereleases (for both packages). - Test the prerelease version to make sure that it's working.
- To test
npm create checkly
, runCHECKLY_CLI_VERSION=4.6.2 npm create checkly@4.6.2-prerelease-c6e8165
(substituting4.6.2
and4.6.2-prerelease
for your versions).CHECKLY_CLI_VERSION
is needed since thecreate-checkly
package looks up the corresponding tag on GitHub to pull project templates.
- To test
- A
production
deployment will be waiting for approval. After it's approved, the#.#.#
version will be published and set aslatest
If you notice an issue when testing the prerelease you can still roll everything back. Simply delete the GitHub release, and delete the corresponding tags from the GitHub UI (both #.#.#
and v#.#.#
).
After resolving the issues, you can create another Github release and go through the process again.
In general, prefer to use Union Types rather than Enums.
Rather than:
enum BodyType {
JSON = 'JSON',
FORM = 'FORM',
RAW = 'RAW',
}
use:
type BodyType = 'JSON' | 'FORM' | 'RAW'
This is especially important in public facing code (the constructs
directory). The main goal is consistency for users. This rule is enforced by ESLint.
If an enum makes sense for a particular use case (internal code), you can explicitly disable the ESLint rule by adding:
// eslint-disable-next-line no-restricted-syntax
Projects are configured to check code linting for staged files before each commit. Also, the commit message must follow config conventions.
After running npm run prepare
and install the git
hooks, before each commit the lint-staged
and commitlint
will check if everything is fine.
If you have a work-in-progress commit, you can bypass the checks using the --no-verify
flag, for example: git commit -m "WIP commit" --no-verify
.