Skip to content
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

Meteor Incompatible with Google Cloud Storage #10984

asafratzon opened this issue Mar 24, 2020 · 2 comments

Meteor Incompatible with Google Cloud Storage #10984

asafratzon opened this issue Mar 24, 2020 · 2 comments


Copy link

@asafratzon asafratzon commented Mar 24, 2020

Hi all.

General Description

Getting build warnings + blank screen on old mobile devices when using Meteor + Google Cloud Storage services. I run Meteor v1.10.1 (OSX) but as far as I can tell this bug was around in older Meteor versions as well.

How To Reproduce

There are 2 different ways to access Google Cloud Storage from node.js:

  1. With @google-cloud/storage library:
    It's enough to run meteor npm install @google-cloud/storage --save and then add const { Storage } = require('@google-cloud/storage'); somewhere in your server-side code to reproduce the build warning. See official docs.
  2. With firebase-admin library:
    It's enough to run meteor npm install firebase-admin --save and then add let admin = require("firebase-admin"); somewhere in your server-side code to reproduce the build warning. See official docs.

Expected Behavior

Successful build and access to google cloud storage services.

Actual Behavior

Having tested both options 1 and 2 thoroughly, I have successfully gained access to google cloud storage services with both libraries. However both generate build warnings.
In addition it introduces compatibility issues with old apple devices (blank screens) which I suspect are related to these build issues because when I uninstall these packages the issues go away.

Here are the final output for each of the setup options:

Option 1 Build Warning (using @google-cloud/storage):

Unable to resolve some modules:

    "worker_threads" in /.../node_modules/write-file-atomic/index.js (web.browser.legacy)

If you notice problems related to these missing modules, consider running:

    meteor npm install --save meteor-node-stubs

Option 2 Build Warning (using firebase-admin):

Unable to resolve some modules:

    "worker_threads" in /.../node_modules/write-file-atomic/index.js (web.browser.legacy)
    "http2" in /.../node_modules/@grpc/grpc-js/build/src/call-stream.js (web.browser.legacy)
If you notice problems related to these missing modules, consider running:
    meteor npm install --save meteor-node-stubs 

Important Notes

  1. meteor-node-stubs doesn't solve these issues.
  2. Looking at this closed issue suggests that the worker_threads related warning should appear only when using node version <= v11.7.0 - but Meteor v1.10.1 uses node v12.16.1. This is the main reason I open this issue in this repository, seems like it's related to the Meteor environment.

Related Info:

@asafratzon asafratzon changed the title Compatibility Issues with Google Cloud Storage Meteor Incompatible with Google Cloud Storage Mar 29, 2020
@benjamn benjamn self-assigned this Mar 31, 2020
@benjamn benjamn added this to the Release 1.10.2 milestone Mar 31, 2020

This comment has been minimized.

Copy link

@benjamn benjamn commented Mar 31, 2020

Thanks for the detailed and easy-to-follow writeup @asafratzon! However, I'm not having any luck reproducing the warning, and I can successfully log the Storage and admin variables from server/main.js at application startup.

Just to be completely sure, what version does meteor --version print when you run it inside your application directory?


This comment has been minimized.

Copy link

@asafratzon asafratzon commented Apr 1, 2020

Thanks a lot @benjamn.
To your question, when I run meteor --version the output is Meteor 1.10.1.

I just looked into it again and seems like you're right - printing the variables from server/main.js doesn't reproduce the warnings. You helped me notice that this issue occurs only if some file that is also required by the client is importing something from the Google Cloud Storage init file.
I hope you could have some advice on my use case, which I think is fairly common.

What I did is put the firebase setup in a imports/firebase.js.
Then I would like to access this connection ref from imports/storage.js.
storage.js contains a singleton which manages my storage - it is an abstraction layer so I won't need to be aware of the request context: from a client context it accesses the storage via the Firebase JS SDK and from the server context it accesses it via the node.js library (e.g. firebase-admin).

I thought it should be possible and easy with Meteor.

When I import the connection ref to this storage.js file (which is also imported by client code), I get the build warning and this warning in the browser:

======== WARNING! ========

firebase-admin appears to have been installed in an unsupported environment.
This package should only be used in server-side or backend Node.js environments,
and should not be used in web browsers or other client-side environments.

Use the Firebase JS SDK for client-side Firebase integrations:

This is totally understandable of course. But I don't understand why when I wrap the usage with a Meteor.isServer check, I don't get the browser message but I still get the build warnings.

I'm a bit puzzled now, because sometimes the use of the library server-side will be initiated by a client context (e.g. the client removes an item from mongo, I would prefer to manage the item storage removal server-side), and in that case, how could I avoid the warnings?

Even if I only import a general string from the storage init file to a client file I get the warnings (I did this test thinking of using a Meteor method for a server-side storage access).

Is this correct behavior? Any assistance is much appreciated.

UPDATE: Workaround Found!

The workaround I found is to put the connection ref inside a global node.js variable, then I can safely access it from other client files without facing any warnings. So in a server-only file, which is ran on server startup:

let admin = require("firebase-admin");
global.serverFirebase = admin.initializeApp(<serviceAccountJson>, <bucketInfo>);

Now you can access the connection (serverFirebase variable) from any other file as long as you're in a server context (Meteor.isServer === true) without any warnings.

I understand that a global variable in node.js is not a good practice in general, but unfortunately using exports as in exports.serverFirebase = admin.initializeApp(<serviceAccountJson>, <bucketInfo>); generate build warnings when imported in other client files (even when usage is wrapped in Meteor.isServer).

I would appreciate any feedback on this workaround before I close the issue. Many thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.