felipepastorelima
felipepastorelima

Reputation: 997

Firebase Functions local "file:" dependencies

I'm using a react-crud-shared as dependency for react-crud-backend which uses Firebase Cloud Functions.

At react-crud-backend I have the following:

{
  "name": "react-crud-backend",
  "description": "Cloud Functions for Firebase",
  "scripts": {
    ...
  },
  "dependencies": {
    ...
    "react-crud-shared": "file:../shared",
    ...
  },
  "engines": {
    "node": "8"
  },
  "private": true,
  "devDependencies": {
    ...
  }
}

At react-crud-shared I have the following:

{
  "name": "react-crud-shared",
  "version": "0.0.1",
  "description": "",
  "main": "src/index.js",
  "private": true,
  "dependencies": {
    "lodash": "^4.17.11"
  }
}

It works fine on development: "firebase serve --only functions", but an error is thrown on deployment:

Did you list all required modules in the package.json dependencies?
Detailed stack trace: Error: Cannot find module 'react-crud-shared'

Is there a way to make it work without having to publish the private repository to NPM?

Thanks

Upvotes: 20

Views: 5311

Answers (4)

stevens
stevens

Reputation: 21

If the goal is to only share module between web and function, you may simple put the shared package under functions as file:react-crud-shared and then reference the package from web using file:../functions/react-crud-shared.

functions/
  package.json
  ...
  react-crud-shared/
    package.json
    ...
web/
  package.json
  ...

in functions/package.json

{
  "dependencies": {
    ...
    "react-crud-shared": "file:react-crud-shared"
  }
}

in web/package.json

{
  "dependencies": {
    ...
    "react-crud-shared": "file:../functions/react-crud-shared"
  }
}

It works perfectly fine for my case since I use shared protobufjs for cleaner typescript.

Upvotes: 2

Hung Nguyen
Hung Nguyen

Reputation: 192

What I have found is that the location of your private package has to be inside your cloud functions folder (default to be functions)

So if you move your private package inside your cloud function folder and set the path of that package correctly in package.json, it should work.

Upvotes: 1

adevine
adevine

Reputation: 1102

EDIT: I found a solution for this that I like much better. I commented on this github issue here: https://github.com/firebase/firebase-tools/issues/968#issuecomment-460323113 . Basically, I have a preinstall script the runs npm pack to copy over the package under the functions directory before I use firebase deploy.

FWIW I have the exact same problem. Not exactly sure how I'm going to solve it, but this information from the doc was helpful (https://firebase.google.com/docs/functions/handle-dependencies):

To specify a dependency for your function, add it to your package.json file. If you are deploying through the gcloud command-line tool, you can also pre-install dependencies and deploy them alongside your function. By default, the node_modules folder is added to your .gcloudignore file and is not uploaded as part of your deployment. To deploy pre-installed dependencies, remove node_modules/ from the .gcloudignore file before deploying your function.

Note: Deploying pre-installed dependencies works with gcloud only; the Firebase CLI ignores the local node_modules folder.

Thus, it appears you could first run "npm install" locally, and then use gcloud for deployment, as it would copy up your node_modules directory, which would have your peer dependency in it.

Really kind of stinks, though, that I would have to switch to gcloud from firebase CLI for deployment. Ugh.

Upvotes: 9

Martin Zeitler
Martin Zeitler

Reputation: 76689

node_modules are (ordinary) being ignored for the deployment;

one can still deploy private modules with a directory structure like that:

functions/
  index.js
  package.json
  react-crud-shared/
    package.json

and a package.json alike that:

{
  "dependencies": {
    ...
    "react-crud-shared": "file:./react-crud-shared"
  }
}

another method would be to blank the ignores:

{
  "functions": {
    "ignore": []
  }
}

just think the first one is better, because this would push the whole local node_modules directory.


beside these workaround methods ...

one can install internally published modules from Cloud Source Repositories, via git+https://.

Upvotes: 2

Related Questions