-
Notifications
You must be signed in to change notification settings - Fork 201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Functions deployment fails when firebase-functions has been hoisted by a monorepo manager like yarn/workspaces or lerna #172
Comments
Hi @rtm everything that functions code needs (including node_modules) must be in the functions sub-directory, since only that folder is uploaded when deploying functions. So your set up won't work unfortunately. |
The gray code sample box in this section lists what the CLI expects your project structure to look like: https://firebase.google.com/docs/functions/get-started#build_the_sample_in_your_firebase_project |
@laurenzlong Many thanks for your response. I've had functions deploying and working just fine for some time now, so I know how to do it. The issue is getting it to work with my mono-repo setup. I don't think it's such a terribly unique use case; many people are starting to use mono-repos, especially with the new yarn "workspaces" feature. It's natural to want to structure my Firebase functions as one (sub)repo within my mono-repo. The way the yarn mono-repo support works, as you probably know, is that dependencies listed in the In the case of firebase functions, I obviously don't know all the internal issues or constraints that are forcing all dependencies to be found directly within the FYI, I tried webpack-ing the code including all the npm packages such as
The code seems to be looking for a JSON file called At that point I ran out of gas and gave up. |
Hey @rtm, if you want to customize the behavior of deployment, here are a couple of options.
|
@laurenzlong Thanks again for your pointers. Yes, I know how to use the As I said, there may be magic things that the logic for deploying functions is doing that make it hard to deal with this scenario. At the same time, monorepos are a "thing" now and I predict that more and more people will be trying to build their The following note from the Lerna site on hoisting might be instructive:
Lerna makes hoisting optional with the I tried using the symlink technique mentioned on the lerna site, symlinking |
Thanks for the thorough response. Can you tell me what else is in your my-repo? And are there parts of your firebase project that are outside of my-repo? |
@laurenzlong Yes, I have a mono-repo, where the sub-repos include one for a Cordova app and one for a desktop/browser webapp (which we call the "console"), as well as one that provides shared Angular components, one that provides standard data types and utilities for standard objects used in the app and console, and then one with some basic JS utilities. And then finally I have the sub-repo that contains cloud functions. All the firebase-related sub-repos (app, console, and cloud) consume (have as dependencies) the common subrepo of types and utilities. Handling these cross-dependencies in a seamless way is one of the main motivations of using a mono-repo. So it looks like this:
I treat the root as the firebase home, which contains The cloud directory has a
The deploy command, from the root, is just
and as mentioned above this picks up the This has all worked fine in various permutations I've tried as I went along. What does NOT work fine is when the My current work-around is just to remove |
This is an issue I'm currently facing. Would this be a feature request that can easily be added via a PR, or are there deeper changes that would need to be made? If a PR is feasible then I wouldn't mind making an addition if pointed in the right direction. |
This would require a change in firebase-tools, and it is not straightforward and in many ways changes the fundamental model that firebase deployment works (not just for functions, but for other features like hosting, database rules) I created firebase/firebase-tools#653 to capture the feature request, please keep future discussions there. Closing this issue, since it is not an SDK issue. Thank you for the thorough description for the request. That is very helpful. |
@laurenzlong Appreciate you taking care of this. It had already occurred to me that this was a cli issue. Thanks for moving it over there. I'll defer to your superior knowledge, but I can't see why there would be implications for non-function deployment. |
If I understand the deployment method of cloud function correctly, at least via the firebase-cli, no Here is what I do as a work around. It's ugly but it works. |
yarn now supports this scenario if you use workspaces:
That's what I do now and it works fine. |
@rtm Does that mean you have no NoHoisted packages in a NPM registry? |
@BrandiATMuhkuh I'm not quite sure what you are asking. |
@rtm I'm talking about when you have a mono repo, where one project/package is the |
@BrandiATMuhkuh You can also put |
Did anyone have success solving that issue? I have exactly the same scenario mentioned by @BrandiATMuhkuh (yarn workspaces, one subpackage depending on another subpackage) and tried to make it work with the above suggestions but was unable to make it work properly. |
Having same problem integrating a utility library in a monorepo. @laurenzlong does each package actually need to be in the npm registry as in no symlinked packages? I guess the question is, is it possible to have it locally import the file via the linked workspace / package json, but at deploy time ignore a package and not try to find it against the registry. |
Yarn solution In your {
// ...
"workspaces": {
"nohoist": [
"**"
]
}
} It basically says, don't hoist anything in this package, so will always retain the node_modules directory. It does marginally slow down installations but I haven't noticed anything drastic. |
This is a really annoying issue. I wanted to be able to share code between my packages, which lerna takes care of through symlinks. My solution is to have pre and post deploy scripts that copy the functions package into a new temporary directory, and use that as the thing that's deployed. It goes into the new temp dir's package json and modifies the version field of the shared package such that it is now of the format "file:./temp_cloned_packages/@mygroup/sharedcodepkg" This is a janky solution, would really like for the firebase cli to support symlinks. |
I am using the workspaces (monorepo) feature of yarn. My
functions
directory is a subrepo. That subrepo listsfirebase-admin
andfirebase-functions
as dependencies, but when installing packages, yarn "hoists" them, so they come undernode_modules
at the top of the repo hierarchy:The problem is, when I try to deploy the cloud functions, I get the message
What is apparently happening is that the deployment logic is parsing the code, and looking for
firebase-admin
directly inside thefunctions/node_modules
directory, and not looking up the node search path as one might expect.The only alternative I can see is to run
npm install
directly inside thefunctions
directory, but that sort of defeats the purpose of having a mono-repo in the first place. Also, I have to redo that every time I run yarn on my monorepo since yarn would think the "local" versions of the packages underfunctions
are unnecessary and would hoist them again. I could remove thefunctions
directory from the list of workspaces, but that would lead to problems linking to other sub-repos.Assuming I am understanding the problem correctly, what I would like to see as desired behavior is to have the Firebase functions parsing logic search for packages up the node search chain, rather than limiting its search to
function/node_modules
.I did try adding symbolic links from
functions/node_modules
to$TOP/modules
. But that fails too, when the Firebase functions parsing logic tries finding dependencies called in byfirebase-functions
etc.Version info
firebase-functions: 0.8.1
firebase-tools: 3.14.0
firebase-admin: 5.8.1
The text was updated successfully, but these errors were encountered: