Closed deldrid1 closed 1 year ago
I wanted to do this also. My initial thoughts:
Yea. node-pre-gyp is usually used for this sort of thing, but since we are wanting to compile for a different target than the npm host that probably doesn't make too much sense? I've never built/maintained a package with binary dependencies.
You could do a custom downloader via scripts(probably similar to what puppeteer itself does), but I think a fork or some awkwardly named branches / versioned releases would be the easiest thing in the short term? It would come with the trade off of maintenance headache (doing everything twice) in the long term.
If warnings during install are acceptable, it could use the approach taken by @ffmpeg-installer, of including a prebuilt bin package for each platform/arch combination in optionalDependencies, with only one surviving install.
Haven't implemented such things myself, just mentioning it as a potential source of inspiration.
I've successfully built Chromium for arm64 and it is working on an EC2 instance (t4g.small), however, it's not working on the stripped down lambda instance. I believe it's not working because lambda is currently running Amazon Linux 2 which doesn't support higher glibc
versions that chromium
seems to require. More investigation required, see #11 for more information
So close, argh! Only meh options come to mind:
Another option seems to be natively compiling chromium on arm instead of cross-compiling, but Google seems to not have that documented or supported.
What would you like to have implemented?
Puppeteer v14 ships with native Apple Silicon (aka ARM) support. According to Amazon, you can see up to a 34% cost reduction by changing architectures to their proprietary ARM processors. I would love to see if this claim lives up to reality by adding support for an optimized ARM based chromium, in addition to the x86_64 flavor.
Several folks have done some preliminary work here - https://github.com/alixaxel/chrome-aws-lambda/issues/241 . Getting an actually maintained release that supports Puppeteer 14+, Node.js 16 (which is finally available), and can run on either architecture would allow for a lot of performance driven testing to optimize Puppeteer at scale on Lambda.
@Sparticuz - With your work on automating the build process, I'm thinking this would be a quick add? Love to know your thoughts and if you would be interested in adding this to your branch (or if I should consider making another fork).