You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that we have a monorepo, we should make devtools aware of it.
If you're developing a language adaptor, you'll be writing it in the monorepo. You want to be able to use the new CLI to test that adaptor against jobs.
If you give the CLI a path to the monorepo, any adaptor imports should load straight from the monorepo.
This can be used a couple of ways:
pass in a monorepo=path/to/monorepo flag (or -m path/to/monotro)
Set an env var and pass a -M flag to the CLI (makes monorepo use easy but still won't load from the monorepo by default)
Some thoughts:
We should load from the build, not the source (this also ensures that .d.ts files are there)
Logging should make it very clear when adaptors have been loaded out of the monorepo (success level logging)
If using the monorepo all version stuff is ignored - no autoinstalls or anything, and any version directives in job code will be ignored
The text was updated successfully, but these errors were encountered:
Now that we have a monorepo, we should make devtools aware of it.
If you're developing a language adaptor, you'll be writing it in the monorepo. You want to be able to use the new CLI to test that adaptor against jobs.
If you give the CLI a path to the monorepo, any adaptor imports should load straight from the monorepo.
This can be used a couple of ways:
monorepo=path/to/monorepo
flag (or-m path/to/monotro
)-M
flag to the CLI (makes monorepo use easy but still won't load from the monorepo by default)Some thoughts:
The text was updated successfully, but these errors were encountered: