Check Run Reporter

Monorepo of common libraries, CLIs, and codegen tools

Table of Contents

• Install
• Usage
• Examples
• On Breaking Changes
• Maintainer
• Contribute
  • nx
  • @clc vs @code-like-a-carpenter
  • Local development without building first
• License

Install

This is a monorepo and cannot be installed in the traditional sense. Instead, each package is published to npm and can be installed individually. For example, to install @code-like-a-carpenter/env, use the following:

npm install @code-like-a-carpenter/env

Usage

Please see each package's README for specific usage instructions.

Examples

Examples can be found in the examples directory. Due to limitations in the free version of localstack, these examples do several things that aren't necessarily recommended in a normal deployment:

• They do not include the ADOT Open Telemetry layer.
• There are no contract tests for API Gateway request validations.

On Breaking Changes

All packages in this repository follow semantic versioning, however, changes that require rerunning codegen are not considered breaking if they require no other interventions.

Maintainer

Ian Remmel

Contribute

PRs welcome, but for anything beyond the most trivial of changes, please open a GitHub issue before doing a whole bunch of work. I'm happy to discuss the additions, but this is a personal project and I don't want you wasting your time if what you're proposing isn't a good fit.

nx

This repo uses nx to manage the monorepo.

.nx-cache-buster

It's sometimes possible to get into a state where the nx cloud cache has cached bad output and it's not clear what inputs are missing from the dependency graph. To fix this, run the following command before using nx:

date --iso-8601=seconds> .nx-cache-buster

Of course, remember to commit the updated file.

@clc vs @code-like-a-carpenter

@clc packages are internal-only. They won't be published but need to be packages for other tooling to work. For example, there's an internal-only nx plugin which is where most of the repo's build configuration comes from. Not only does this plugin need to a different package.json layout (it's main entry needs to point to a typescript file, not a built file), it just wouldn't make sense outside the context of this particular repository.

Local development without building first

In addition to cjs/esm entries in each package's export map, there's also a carpentry entry which exports the typescript source code. By setting NODE_OPTIONS='--conditions=carpentry, nx should be able to use project code without building it first.

If you're debugging a cli, you can also --import tsx during development to run without building everything first:

NODE_OPTIONS='--conditions=carpentry --import tsx' npx @code-like-a-carpenter/cli

This approach isn't fully compatible with nx yet. By setting --import tsx, nx ends up with libraries vying to import typescript files and errors. Since --import cannot be set on the environment when using nx, nx cannot call local clis that need to be transpiled on the fly. Either they need to be build before they get invoked as an nx target or (prefferably), they would also export an nx executor that can be called directly. If we don't need to shell out to a subprocess, we can rely on nx's automatically registered swc/node

License

MIT © Ian Remmel 2019 until at least now