Payload size is big #332
jeanbmar
started this conversation in
Feature Requests & Ideas
Payload size is big
#332
Replies: 7 comments 6 replies
-
|
Hey @jeanbmar — thank you VERY much for sharing your research and your thoughts here. We are going to address this immediately. I bet we can shave off some size right away, and I would certainly like to reduce Payload's SCSS webpack requirements (most all of those For the above reason, regarding dev dependencies vs. dependencies, I believe most of our dependencies will need to remain as regular dependencies so end Payload users can run Give us a bit here and we should be able to clean this up pretty well. Again - thanks for your research and thoughts here! |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
Hey @jmikrut Thank you for your quick response. On our side everything is built before the app is shipped to prod, but I totally understand that we all work differently. Thanks anyway for any cleaning you will do! |
Beta Was this translation helpful? Give feedback.
-
|
It seems that this has gotten 'worse' and the size is now up by a lot especially due to relying on (what usually are) dev dependencies like (edit: this might seem a bit flamy. Just wanted to state I'm trying to contribute) |
Beta Was this translation helpful? Give feedback.
-
|
I'm building remotely and my docker images are >1.5GB that devour space in the registry and always needs to be pulled. (most of it is cached, but still ~600MB bounces back and forth. Were there any reasons why you did not use it when you already leveraged it for UI. And I wonder is this on a roadmap to include this functionality in payload, or do you view it that it should be implemented on project-basis? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@jeanbmar did you manage to get Payload up and running on AWS Lambda? I'm currently experimenting with AWS Amplify and experiencing some issues, among which is the package size, as you've mentioned. |
Beta Was this translation helpful? Give feedback.
3 replies
-
|
@hdodov Yep, with 2 steps:
rimraf node_modules/postcss* node_modules/date-fns node_modules/@jest node_modules/node-sass node_modules/terser*"Should I do it again, I would deploy the Lambda using a Docker container though. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, that's exactly what I'm planning on doing - using a Docker container. Installing sharp is a huge pain with the Amplify CI/CD. The pre-built binaries don't cut it, so you need to install libvips, build it from scratch, and wait ~15 minutes for the entire build to finish… |
Beta Was this translation helpful? Give feedback.
-
|
@jmikrut In order to avoid installing unnecessary packages on the server side, it seems necessary to relocate certain dependencies to devDependencies. Have you thought about using Jimp instead of sharp for image resizing? |
Beta Was this translation helpful? Give feedback.
-
|
Hi, mentioned about size like 300Mb (AWS limit is 250 Mb), i hope its changed from 128 MB to 10240 MB |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Any improvements on this? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Unfortunately building payload cms for any kind of docker-image pipeline currently is a nuisance. Payload CMS is fantastic product, but not for those fancy containerized pipelines. I have nextjs with payload and my whole docker image is > 900mb. Steps that can help one that is seeking answer to packing project into docker image for some kind of pipeline:
If you have additional info how to pack everything tightly in Payload CMS - please consider writing here and tagging me, I'm very interested how some kind of pipeline can be achieved without space hogging process :D |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Amazon reports that our images in ECR are about 330mb. We use github actions to build the images and then ship them to aws ecr and run them via ecs fargate. Works well and doesnt take long to build or deploy. We havent done any work to try to reduce the size of the images other than the multi stage build. This is our Dockerfile |
Beta Was this translation helpful? Give feedback.
-
|
The dependencies in the 3.0 branch are being reduced significantly. I'm not going to give a number because it might still shake up or down before the beta is released. I think it will solve this exact problem, hang tight! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hey there,
We are working on deploying Payload serverless using AWS Lambda.
Right now we have a big issue: Payload is so big that we can't deploy it on AWS.
The node_modules directory size is higher than 300Mb (AWS limit is 250 Mb).
Besides the size issue, packaging Payload using Serverless takes more than 6 min.
I've had a quick look at the dependencies and I feel like some dependencies should actually be dev dependencies.
After installing Payload using
npm i --legacy-peer-deps --production, I ran a size check on my local Windows and got the following result for all the deps higher than 1 Mb:It feels too big. The
postcssdependencies alone weigh more than 80 Mb.I'm not a front expert but I see many dependencies that I assume are required at build time but should not be required in a production environment.
depcheckalso points that the following dependencies aren't used at all:The list is probably not accurate (e.g. I've seen assert in some code), but I think it's worth a check (e.g. couldn't find any dotenv reference).
Overall it would be really great if you could do a quick review of all the deps and make sure dev deps aren't listed in the wrong place 😊.
Thanks for your time and your work!
Beta Was this translation helpful? Give feedback.
All reactions