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
This is a second proposal to solve the core problem described here: #65. Namely, I'm trying to construct a TypeScript monorepo with "live types" across package boundaries.
To do this, I'm now attempting to a custom "typescript" export condition that points to my TypeScript source code. I can then configure compilerOptions.customConditions such that TypeScript looks at the raw .ts source of my local packages in development instead of the .d.ts artifacts.
Currently tshy overrides everything in "exports" including any custom conditions I'd like to define. This could be resolved with a general-purpose "overrides" field that gets deep-merged into the generated package.json.
Is exports the only thing that it'd be able to override? It feels like it could just be called exportsOverrides or something in that case, and then the logic is just that it'll be deep-merged on top of whatever else tshy generates. So kind of a general purpose manual escape-hatch for whatever.
This is a second proposal to solve the core problem described here: #65. Namely, I'm trying to construct a TypeScript monorepo with "live types" across package boundaries.
To do this, I'm now attempting to a custom
"typescript"
export condition that points to my TypeScript source code. I can then configure compilerOptions.customConditions such that TypeScript looks at the raw.ts
source of my local packages in development instead of the.d.ts
artifacts.Currently
tshy
overrides everything in"exports"
including any custom conditions I'd like to define. This could be resolved with a general-purpose"overrides"
field that gets deep-merged into the generatedpackage.json
.This config would result in something like this:
The text was updated successfully, but these errors were encountered: