anyone have experience deploying typescript aws la...
# typescript
h
anyone have experience deploying typescript aws lambdas with pulumi? I’ve attempted to use both
aws.cloudwatch.onSchedule
and
new aws.lambda.Function
to create the typescript bundle. I can’t seem to get dependencies pulled in correctly. I either get errors like
which could not be serialized because it was a native code function
or
Could not include required dependency
. I feel like I’m missing something obvious
I’ve read through the docs - https://www.pulumi.com/blog/lambdas-as-lambdas-the-magic-of-simple-serverless-functions/ and a few related issues but the general theme seems to be this should just work
f
Are there other libraries you’re trying to pull? Could you please share your code?
l
Have you tried using
require
within the function to import your dependencies? For example: https://github.com/pulumi/examples/blob/master/aws-ts-serverless-datawarehouse/datawarehouse/partitionRegistrar/index.ts#L28
h
Unfortunately I’m not able to share the actual code but I’m attempting to reuse other internal modules within a lerna repo. I’ve tried
Copy code
export const handler = async () => {
  const { foo } = await import('@interal/foo');
  ...
};

aws.cloudwatch.onSchedule('FooFunction', 'rate(10 minutes)', handler);
this gets farther but then I get a bunch of warnings like
Could not include required dependency '@interal/foo'
and nothing gets pulled in
f
what does the lambda that gets created look like? does it include
@internal/foo
? I also assume you checked that
@internal/foo
does exist in your local
node_modules
?
i’m wondering if those internal modules are at the root node_modules of the lerna repo and not local to the package.json where your pulumi program lives?
l
@high-lamp-12603 can you try to
require
all of your dependencies from within the function instead of using
import
?
m
Running into the same issue and the only way to fix it is to require inside the function which isn’t ideal. In my case it’s a very simple function that uses
@google-cloud/pubsub
and it’s quite a different way to write code to think to put it within the function.
h
@faint-table-42725 all dependencies are in the root node_modules
It sounds like Pulumi just isn’t compatible with lerna/yarn workspace based on: https://github.com/pulumi/pulumi/issues/2661 https://github.com/pulumi/pulumi/issues/2980 Is there a better option than bypassing all the Pulumi lambda conveniences and bundling the zips manually?
f
But what about the node_modules local to your pulumi program’s
package.json
? If not, I believe the code that walks the tree to find your modules will stop there. If that’s the case, one thing you could try is using
codePathOptions
h
Hey @faint-table-42725 thanks for the help. Moving all dependencies including to the same
package.json
did fix the pulumi warnings but resulted in the same lambda bundle with no dependencies. For
codePathOptions
are you suggesting setting
extraIncludePath: $WORKSPACE_ROOT/node_modules
? I tried this but it ends up serializing the entire repos dependencies causing pulumi to hang
f
Interesting — I’m surprised that moving them locally didn’t work.
So if your directory structure is something like
$WORKSPACE_ROOT/sub/project/package.json
(where you moved the deps)
h
the uploaded lambda is invalid because it kept the typescript type references
f
and there’s a
$WORKSPACE_ROOT/sub/project/node_modules
— the ones you moved would have those dependencies, right?
h
I have something like
Copy code
$WORKSPACE_ROOT/
  package.json
  node_modules/
    ...all dependencies
  projects/
    p1/
      package.json
      index.ts
previously p1/package.json had the pulumi modules as dependencies leading to the
Could not include required dependency
warnings. then moved all dependencies up to
$WORKSPACE_ROOT/package.json
. that fixed the warnings but still nothing added to the bundle
f
And
Pulumi.yaml
lives in
p1
?
h
I’ve tried both in
p1
and in the root
f
I guess the issue is really where
index.ts
lives I think actually.
And how it searches relative to it
It reads from the cwd
h
which doesn’t seem like it will read from the root
package.json
at all
f
Then, afterward, it will the extraIncludePaths
But, as you can see there, it’s not doing anything smart and just trying to include everything
h
Yup which leads to a massive bundle in my case
unfortunately sounds like webpack/parcel are the better option for now
f
Yeah, sorry 😞
I think you could probably pull it off
if you included the modules one-by-one via extraIncludePaths
h
yea but that’s not really maintainable especially with nested dependencies
f
yeah
i agree
h
well thanks for the help either way!