Guidance on using with Typescript and Yarn workspaces #265
Comments
|
If size is the main issue, you should really just look into trace mode, which doesn't need any special config for yarn workspaces (other than maybe symlinks which should work fine). You would remove the Best bet if you're spinning your wheels is if you can get me a public skeleton repository and then I could tweak your config in a PR / diff to tune it. Here's a good reference configuration using trace mode: https://github.com/FormidableLabs/aws-lambda-dogs/blob/main/serverless.yml Good luck! |
|
Thanks @ryan-roemer I'll have a try with a skeleton repo tomorrow. It's clear why size is the issue - it's including aws-sdk and other dev dependencies, even though I have them to not be included (both using ! and also I've tried under exclude). |
|
Ok using trace, this is the best I've gotten: https://github.com/mikkel-pearl/jetpack-test Service 2 references a function in Service1 and it gives the error I've tried adding Any advice? (Also on a side note, I've noticed that it looks like jetpack doesn't support Typescript path aliasing - is that right?( |
|
So you're using legacy mode, which like normal serverless infers dependencies off reading your Also, as a side note, it's best to run serverless from the root of the repo if possible as there are lot of gotchas with having deps below CWD -- see: https://github.com/FormidableLabs/serverless-jetpack#packaging-files-outside-cwd generally. However, Jetpack does support it. But things like My current working diff that I think does what you want: diff --git a/packages/service2/package.json b/packages/service2/package.json
index 0c6be05..c55552d 100644
--- a/packages/service2/package.json
+++ b/packages/service2/package.json
@@ -6,9 +6,13 @@
"scripts": {
"build": "npx tsc --project ../service1/tsconfig.json && npx tsc"
},
+ "dependencies": {
+ "@jetpack-test/service1": "*"
+ },
"devDependencies": {
"@types/aws-lambda": "^8.10.81",
"aws-lambda": "^1.0.6",
+ "serverless": "^2.52.1",
"serverless-jetpack": "^0.11.1",
"tsconfig-paths": "^3.10.1",
"typescript": "^4.3.5"
diff --git a/packages/service2/serverless.yml b/packages/service2/serverless.yml
index c3b985c..ae3e8cb 100644
--- a/packages/service2/serverless.yml
+++ b/packages/service2/serverless.yml
@@ -7,8 +7,24 @@ useDotenv: true
frameworkVersion: '2'
package:
include:
+ # Step 2: Service-level configurations
+ #
+ # **NOTE**: When globbing _below_ CWD you need to add a separate pattern
+ # in addition to a normal `**` which won't reach below CWD.
+ #
+ # E.g. for just `aws-sdk`, we need:
+ - "!../../node_modules/aws-sdk/**"
- "!**/node_modules/aws-sdk/**"
+ # Step 3: All the function-level files you need to include.
+ #
+ # I've separated this here because if you have multiple functions, you
+ # would switch to `package.individually = true` and then move this into
+ # `function.{NAME}.package.include`
+ #
+ # Add more for this function here!
+ - "dist/**/*.js"
+
custom:
scriptHooks:
# These are all the places that jetpack could be invoked that would
@@ -16,11 +32,16 @@ custom:
before:package:createDeploymentArtifacts: yarn build
before:package:function:package: yarn build
before:jetpack:package:package: yarn build
+
jetpack:
# Search for hoisted dependencies to one parent above normal.
base: "../.."
- roots:
- - "../service1"
+ preInclude:
+ # Step 1: Start with no files at all.
+ # Serverless by default includes all `**` to start. This custom
+ # Jetpack configuration allows us to override it for a slimmer
+ # starting point.
+ - "!**"
plugins:
- serverless-jetpack
@@ -45,4 +66,4 @@ functions:
- http:
path: '/service2'
method: GET
- cors: true
\ No newline at end of file
+ cors: trueWhen I build, I use Jetpack's Here's a sample run: $ cd packages/service2
$ yarn serverless --stage dev jetpack package --reportAnd here's the output as of my diff: |
|
Awesome! Thanks so much for getting back so quickly. That is superb. I now have my test repo working and there is one last bit on my actual repo that is a blocker - which is the ts path aliases. I assume there isn't a clean way to incorporate these, so I've tried a wildcard under allowMissing but that doesn't seem to work: It does work if I fully qualify the path, but considering we use type aliasing for every single internal import that's not practical. Is there any way forward here? If I can get this I'll definitely write a blog post about it and push to get jetpack to become the de facto way of bundling modern monorepos. |
|
Can you update the test repo config and source to exhibit the same type of problem in your actual repo? |
|
Is the resulting transpiled (dist) code actually runnable server-side by Node.js? In your “@jetpack-test/service1” example, that would be runnable in Node. The “@/service1” construct doesn’t look like valid Node code (because it’s a package that could not really exist). Jetpack is meant to package individual files that can run in a Node environment. Unfortunately it looks like your output (dist) code is not Node runnable and instead requires either a build step (webpack, etc) or a different runtime (ts-node, etc.) |
|
If you have a scenario of actual Node runtime compatible files, please do update the example repo and I’ll dig back in! |
|
Yes it is runnable in node with a little trick I have pushed a commit that compiles and runs a plain node command. You can see it by doing I know this is a bit of a stretch, but it looks like tsconfig-paths has gotten it working with various tools that use plain node through preregistering too. |
|
I was concerned that tsconfig-paths was not used very much, but that's not the case:
|
|
Ah, so yeah a ts or Babel register actually patches how Node runtime works and are generally discouraged from production usage. (They not only change Node internals but add extra overhead as they mutate code at runtime). I will take a take a look at your jetpack-test repo if you have an update for me to work with and see if I can get a hack or bandaid or something. But I would also encourage you to consider transforming your final output code to something that works in straight node for perf and general tooling ease… |
|
OK cool, I've found a different approach where it uses a transformer while compiling the typescript to js. I've just pushed a version using that - I think this should work! Thanks for all your help |
|
YES! It is working Thank you for putting in all the time to figure this out with me. I spent over a week trying to get it to work and there are lots of people that have been trying to get similar setups going on the net, but nothing is consistently succeeding. I'll be sure to write this up and show how it's done. |
|
Awesome! Looking forward to the write up. And thanks for taking the time to push example code to |
Hey there, Jetpack looks great and I am hoping to be able to use it after struggling with serverless-webpack for the last few days.
I have a typescript monorepo using yarn workspaces, and found this issue in which you say to build manually with a script. However, it's not clear how to configure this with Jetpack. Right now I have
This is including my entire hoisted
node_modulesfolder (including aws-sdk, typescript, other dev dependencies, etc) and so is too large for lambda. Further, it's not clear how to connect it to the function.Would it be:
???
Any guidance is much appreciated. Thanks
The text was updated successfully, but these errors were encountered: