There seems to be more convention instead of confi...
# sst
e
There seems to be more convention instead of configuration for sst cli. We could use “sst-esbuild-config.js”, or make it a cli flag?
f
Hey @Erik Mikkelson, you mean you are using decorators in your SST code, right?
e
Our database code is using decorators, yeah. I can also see some cases where we might use decorators to generate constructs. For example, look at this repository which is using the metadata to generate resources https://github.com/jetbridge/jetkit-cdk/search?q=metadata
The choice to use esbuild everywhere was consistent, but being locked out of aspects of typescript that we would get in normal CDK (i’m thinking the cdk.json (“app”: “npx ts-node --prefer-ts-exts bin/demo-ts.ts”,) can cause some headaches if I’m not expecting it. I’d almost prefer that normal cdk is used for everything except the start command (which really only needs to watch the lambda functions right?) The lambas could be build as normal for the deployment scenario and the start script would do its thing about swapping in the jump function and discovering functions to build and watch locally. Still new to the code so I’m figuring out what goes where and why, please don’t take it as criticism of an amazingly useful kit!
f
Oh no, it’s a legit question! It’s been brought up before. Let me write something up on why it’s designed this way, and put it up publicly on our docs for critics. I will share it here once it up .
As for now, as you suggested, let’s add an
esbuildConfig
param to the
sst.json
. I’m also thinking to make all functions respect this flag by default.
p
^^ that seems like a good solution.
e
@Frank I can take a look at that tomorrow (it’s related to something I’m working on) if you don’t mind the PR
f
That’d be awesome! A quick note on the
typeCheck
and
linting
config in
sst.json
. They are being used for type checking and linting both the CDK code and the Lambda code. You can reference how they are being passed around 🤓
e
PR is up at https://github.com/serverless-stack/serverless-stack/pull/575. I did not add the defaultFunctionProps change, though I’m assuming if we did that it would go in cdkwrapper/run.js where the app props are passed in.
f
Awesome! I’ll take a look at it today.