Skip to content

Monorepo of common libraries, CLIs, and codegen tools

License

Notifications You must be signed in to change notification settings

code-like-a-carpenter/workbench

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Workbench

standard-readme compliant Dependabot badge

Monorepo of common libraries, CLIs, and codegen tools

Table of Contents

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:

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.

License

MIT © Ian Remmel 2019 until at least now