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

Add a console warning when browser bundle is loaded in node. #1536

Merged
merged 4 commits into from
Feb 20, 2019
Merged

Conversation

hsubox76
Copy link
Contributor

Partially addresses issue #1415.

Open to suggestions on what the message should recommend to the user.

Tried a rollup node test project and browser webpack test project. Warning is seen in node, not seen in browser.

isNode &&
console.warn(`
Warning: This is a browser-targeted Firebase bundle but it appears it is being run in a Node
environment. This may be because you are using ES module resolution and the Node bundle is
Copy link
Member

@Feiyang1 Feiyang1 Feb 15, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not clear to me what ES module resolution means. It's probably better to just state please use the "main" field in package.json for node bundle.
We can also add the link to webpack doc - https://webpack.js.org/configuration/resolve/#resolvemainfields
and rollup doc - https://github.com/rollup/rollup-plugin-node-resolve

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Modified the text.

@hsubox76 hsubox76 merged commit a18b290 into master Feb 20, 2019
@hsubox76 hsubox76 deleted the ch-warn branch February 20, 2019 18:27
@arpowers
Copy link

The solution you guys are proposing is not going to work. Also you give no ways of debugging this issue since Webpack is compiling normally with the 'node' target set.

@arpowers
Copy link

arpowers commented Mar 14, 2019

it says here:
https://webpack.js.org/configuration/resolve/#resolvemainfields

A node targeted Webpack build will load 'module' first, YET, you've added this warning to the index.esm.js entry ( which is the firebase entry for 'module' )

Also changing Webpack global config is NEVER going to work - as you'll cause way worse bugs from other packages with this approach.

Also things were working fine for me before, and you guys have not provided a way to disable this huge warning message.

@Feiyang1 @hsubox76

@Feiyang1
Copy link
Member

Feiyang1 commented Mar 15, 2019

Thank you for the feedback. And sorry you had a bad experience.

To clarify how fields are used in firebase currently:
main: cjs build for Node
module: esm build for browser
browser: cjs build for browser
react-native: cjs build for react-native

Each firebase SDK (except storage) does something different for Node, so the browser version should really not be used for Node environment. and it could cause issues down the road if you are already using it, so I think the warning message is warranted.

We have both cjs and esm build for browser because we want to support as many workflow as possible, for example, browserify only works with cjs natively.

I'd like to have a browser-module field, so I can use module field to point to node version, but I don't think there is something like this at the moment, so we chose to use the module field for the browser build.

I'm open to suggestions, but given the constraint of a single module field, I don't know what more we can do than giving a warning message when a bundle is used in the unintended environment.

I'm not convinced that changing the global resolve.mainFields to read main field first is going to cause issue for other packages as all node packages should have a cjs build pointed by the main field.

If you are really worried about it, you could do something like:

  resolve: {
    alias: {
      firebase$: path.resolve(__dirname, 'node_modules/firebase/dist/index.node.cjs.js')
    }
  }

Anyway, thanks for voicing your concern. If you'd like to continue the discussion, please open an issue, so we can track it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants