[FEATURE] Add custom folder path option for Smithy-generated handlers
Describe the feature
Add an option in the Smithy handler trait to define a custom folder path for the generated handers.
Use Case
Current settings generate all handlers inside the src and test folders with a flat hierarchy. Need an option to customize the individual handler path.
Proposed Solution
Add a new optional subdir option to the Smithy handler trait?
Other Information
We may also need to add this option for async handlers.
Acknowledgements
- [X] I may be able to implement this feature request
- [ ] This feature might incur a breaking change
PDK version used
0.23.66
What languages will this feature affect?
Typescript, Java, Python
Environment details (OS name and version, etc.)
Linux, Windows etc
I think the tricky part for typescript will be getting the esbuild command right to bundle all the handlers - I wonder if we'd need to make it more generic so it finds all ts files in the target directory which export a function called handler? :) Not sure exactly the best way to achieve this though - could maybe add a new script to run.ts but it might increase the size of the bundled run.js that ends up in the PDK distributable as that itself would then include esbuild!
I think we may need an index file to store the paths of the generated handlers. Is it possible to read handler data from the model/.api.json file? I'm not quite sure how these projects are linked together. If we choose to scan all files in src/**/* directory, we can run a command with a regex and pass the result to the current esbuild command.
We can read the model/.api.json at build time (just not at project synthesis time as users should be able to add an operation and just rebuild rather than having to re-synthesize too).
So yes I think we could have a script/command read model/.api.json to find where all the handlers are and pass that to the esbuild command :) Ideally I think we'll want this as a node.js script which we can then pass the output to esbuild, so it's as platform agnostic as possible :)
This issue is now marked as stale because it hasn't seen activity for a while. Add a comment or it will be closed soon. If you wish to exclude this issue from being marked as stale, add the "backlog" label.
Closing this issue as it hasn't seen activity for a while. Please add a comment @mentioning a maintainer to reopen. If you wish to exclude this issue from being marked as stale, add the "backlog" label.