Most of the examples use a single `index.ts` to de...
# general
q
Most of the examples use a single
index.ts
to define all resources
The examples that don't, use other files to provide templates or constructors for component resources
Is it possible to split up resource creation into multiple files? Without weird import and exporting within
index.ts
? I don't feel I have much control over the repository hygeine
Is this just a TypeScript limitation? Should I use Go?
w
You can generally split files up anyway you want, and then just
import
implementation details into the places they are needed. This doesn't have to align 1:1 with components - though sometimes that will make sense. But if the implementation of a component is very large, you can split it into several files and then import those details into the module that actually implements the component. One common pattern is to move the component (or area of functionality generally) into a folder, and put an
index.ts
in there that exposes the "API" for that area of functionality, and imports details from other files within that folder.
q
So if I define lots of resources across 4/5 different
.ts
files, what should be set as
main:
inside
package.json
?
w
You can pick one file to import the others - and probably to provide a consistent set of exports for the stack - and then point at that from
main:
. Do you have an example of the kind of thing you'd like to work but that doesn't?
q
So my
index.ts
would need to import all resources from other files, only to export them again; is that correct?
w
In general it shouldn’t need to export everything, just whatever the “API” to that subset of the deployment looks like. (Or just the stack-level exports at top level).
q
Is this something that can be improved? Can the exports from all files be collated ?
w
You can collate the exports form “all files” by adding an index.ts that just does:
export * from “./other”
For each of the files you want to include in your stack exports. Do you just not like having this additional file? The benefit of this file is that it makes clear what you intended to be the stack outputs in one place, vs just having exports spread throughout your files. This also generally makes the other files more reusable in other contexts where they may be used as part of a project with different stack exports. Definitely would be interested to see a concrete example of the pattern you are using that is causing this to be problematic to understand what we could do to help.
q
@white-balloon-205 I wasn't aware of that
export *
syntax, that's perfect. Thank you for your continued patience and help!
👍 1