SSTConstruct: Add optional resource type to function binding

[floriangosse]

Introducing an optional property called resourceType on function binding props so that we can explicitly define the resource type that should be used for type generation. This allows us to build custom SST constructs that can be injected into SST's type generation and variable population.

An example would be a custom database construct that can be bound to functions as well. Right now it would mean that we have to call the construct's class RDS just so that the types will be generated correctly and the variables are available via the sst/node/rds package. With the new property resourceType I can name my custom database construct however I want and can just set the resourceType in getFunctionBinding to RDS and the variables I define will be available via sst/node/rds.

[changeset-bot]

⚠️ No Changeset found

Latest commit: e17fbc4

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[jayair]

Oh this is interesting. This PR is a bit complicated but I like the underlying problem you are trying to solve. Let me share this with the team.

[floriangosse]

I thought about a simple solution and I've decided to just use a string type. Another idea I had was to work with a enum or other predefined constants for RDS, Function, etc.

Let me know if I can help you with any more details.

[floriangosse]

I found another thing that needs to be adjust to work properly: in case of the RDS construct there is the warmer that uses RDSDataAPI to talk to the database.

I've "misused" the RDS namespace for my own Database construct which isn't relying on the DataAPI. So, the warmer throws an error after some time.

There are probably more parts of the whole tooling that might not work as expected I don't know about it.