tl;dr: It is now officially supported 🎉!
As part of an AWS to GCP migration, we wanted to leverage Google Cloud Functions (https://cloud.google.com/functions) to help us scale our infrastructure in a more manageable manner.
Cloud Functions are written in JavaScript and execute in a standard Node.js runtime environment.
How great is that? — so we thought. Instead of migrating our AWS monolith, we decided to extract isolated pieces and deploy them as independent services, one piece at a time. Our existing application is written in Node.js and migrating to GCF (Google Cloud Functions) sounded straight forward. If it wasn’t for our private NPM packages…
A note for clarity, GCF has always worked beautifully if you only rely on public npm packages.
Private NPM Packages — The Problem
In order for our teams to share common code, we use private npm packages. GCF did not like that… There’s a StackOverflow discussion with a workaround. It works great if your code has top-level dependencies that are private npm packages. If, like in our case, you have transient dependencies that are also private npm packages, you either get really creative with your scripts or look for alternatives. In our case, we deployed to Google App Engine, which was a temporary workaround as it becomes very expensive very quickly…
Private NPM Packages — The Solution
Yesterday, I ended up on the GCF docs by accident (yeah stuff like that happens) and found a new chapter “Using private modules”. Wait what? Whaaaat?
In order to use a private npm module, you have to provide credentials (auth token) for the npm registry in aÂ
.npmrcfile located in the function's directory. You can simply copy theÂ.npmrcfile that was created in your home directory when you logged into npm using thenpm logincommand.
That’s the entire chapter and it is such a game changer!
Let me know in the comments if this makes your decision simpler to migate to GCF. Have questions? Ask away, I’m happy to help out wherever I can.