Closed mattdelsordo closed 6 years ago
This is kind of a bummer. Two ideas that come to mind as alternatives for making the package smaller without removing functionality:
carto
locally: we could compile the map-config.mml
to XML locally and push the XML into the bundle. Then we could move carto
to devDependencies
node_modules/carto
is devoted to the docs/
subdirectory.I wouldn't be opposed to removing the message tiles for now, but I think they're nice and it would be worth coming back to it later if we do. I.e. merge this but open an issue about putting them back. This is a nice self-contained commit that would make it easy to restore them.
I was trying to brainstorm ways to slim down the size of the bundle that gets sent to AWS, and now that you mention it, webpack seems like it could be the solution to that problem. In terms of Carto, it's really only ever used locally, it would be totally feasible to make it a devDependency. I'll make that change and see what happens. I have an issue open for shrinking the size of the AWS bundle (since it would improve lambda startup time) and that might be a good place to pop message tiles back in, if the devDependency thing doesn't work out.
EDIT: Yep, simply moving Carto to devDependencies does solve the issue. I'm going to close this PR and make a new one.
Overview
jimp
was pushing the size of the lambda function bundle over AWS Lambda's upload limit and blocking deployment attempts. Unfortunately, this makes it not worth it to have as a dependency just to support error message tiles, although they were nice.For reference, the breakdown of dependency size is as follows: The 34.1M bundle size doesn't account for mapnik (the tool I used couldn't figure out what to make of the C++ bit of it, I think), which should push the whole thing over AWS's limit of 70M (apparently).
Notes
There are actually ways to circumvent Lambda's upload limits (such as storing the files in S3), but I didn't think adding additional infrastructural complexity was worth it for a non-essential feature.
Testing Instructions
./scripts/publish --new
or./scripts/publish
, it should publish successfully (unlike on develop).Resolves #70