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
It would be great to be able to disable the generation of sst-env.d.ts for a specific package or a group of packages mostly likely by having a configurable exclude pattern.
By the current SST logic everything in packages/* gets given an sst-env.d.ts even though I would rather it not have one.
In practice I don't want anything in packages directly touching the infrastructure as they are designed to be self-contained packages such as what would potentially be publishable to npm. Not having the types helps to force separatation and cleans up the Git diff everytime a resource with links is changed in SST.
We have the same problem. What would be even better if SST was somehow able to generate sst-env.d.ts tailored for each package (I guess based on handler paths and their links? I can imagine it's quite tricky to do it right) - it's pretty annoying that every change in SST config results in like 20 changed files even though it realistically only affects one of packages.
It would be great to be able to disable the generation of
sst-env.d.ts
for a specific package or a group of packages mostly likely by having a configurable exclude pattern.For example my monorepo at it's root has:
sst.config.ts
packages/*
apps/*
By the current SST logic everything in
packages/*
gets given ansst-env.d.ts
even though I would rather it not have one.In practice I don't want anything in packages directly touching the infrastructure as they are designed to be self-contained packages such as what would potentially be publishable to npm. Not having the types helps to force separatation and cleans up the Git diff everytime a resource with links is changed in SST.
Broken out from my comment in #1017.
The text was updated successfully, but these errors were encountered: