-
Notifications
You must be signed in to change notification settings - Fork 896
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
"Can't resolve encoding" warning in the console when used with Next JS 13.4 #7280
Comments
Hi @raajnadar, thanks for reaching out. I was able to replicate the behavior that shows the warning when using Next JS 13.4. Let me check what we can do for this issue or bring someone from the Auth team that can provide more context about it. I’ll update this thread if I have any information to share. |
There is a WIP to update the node-fetch version, but it has some CI failures which needs investigation - #5476 Can you clarify which node-fetch version resolved the issue for you? Thanks! |
@prameshj in the CI logs it seems there are typescript errors which can be resolved easily |
Can this be added to the package? |
https://nextjs.org/docs/architecture/supported-browsers#polyfills Next.js replaces
If necessary, dynamically importing node-fetch is preferable since |
We will try to upgrade node-fetch to v3 if possible. It looks like this will not be fixed in any version of node-fetch v2: node-fetch/node-fetch#675 Dynamic imports would be a larger change, we have avoided including dynamic import statements in the SDK for a while because not all environments support them. It may be time to revisit this as support has increased a lot in the last few years. It still doesn't work in Node 12 and below so at the very least we'll have to bump the latest version of Node we support and put it somewhere in the docs. We'll need to do a thorough review to explore what other unusual environments might not be covered, e.g. React Native, browser extensions, incognito/private, service workers. |
We're still working on updating node-fetch to version 3 as described in the above comment, for what it's worth this issue in the Next.js repo says it's just a warning and it shouldn't break anything: vercel/next.js#7621 |
I totaly agree with you, but this warning is spammed on terminal which makes it difficult to read logs on dev mode |
Would the installation of |
@hsubox76 I recommend simply not including FWIW, Next.js also polyfills |
Thanks for the info! We haven't specified a minimum version of Node we support, but we're working on a policy, hopefully tied to Node's own EOL schedule. I think the highest minimum explicitly set right now is 10 on Firestore so we may have users that still expect 10 or at least 12 to work even though we haven't made any official guarantees. Dynamic imports are something I'm hesitant about for the reasons above, but maybe we could import undici in all cases and only call it if globalThis.fetch is undefined. I think users' bundlers should then tree-shake it out if it's not used, if they are using tree-shaking. |
next.js will remove node-fetch |
@matamatanot it has already been removed 4 months ago, in favor of |
It makes me happy |
'fetch' is now stable! |
Time to fix this guys 🙏 |
We're actively working on this. The challenges we're running into are:
Given that, we're currently taking a shot at seeing if we can migrating
|
btw why do you have to use |
It's not an issue of our own code being in CJS. We export both CJS and ESM bundles. Most of our products that support both browser and Node have at least 4 bundles - browser CJS (Jest/JSDOM requires this), browser ESM, Node CJS, Node ESM. As a library, we have to support a broad range of developers, including those that can't update to the latest technology due to various reasons, such as having required legacy tools and dependencies that are not yet updated. Firebase is used by all kinds of developers on all kinds of platforms, including browsers, browser extensions, service workers, Node, edge, native webview (Cordova/Ionic), React Native, Flutter, Electron, smart TV OS'es, in greenfield apps and in large legacy codebases mixed in with other many other libraries. We do our best to support developers in as many cases as we can, and this sometimes prevents us from being able to use all the cutting edge technology and telling developers who aren't able to upgrade, or are on the wrong platform, to just deal with it. We obviously can't support every environment forever (we recently dropped IE) but we have to walk a fine line between reasonably dropping support for very old, unused environments and just leaving 50% of our Node users with broken apps suddenly. Also, as I mentioned above, we're trying |
any update on this? |
We merged a PR to upgrade the older |
v10.7.0 with the aforementioned change to undici has been released. I'm going to close this issue for now. If you still have problems related to this ticket then please open a new ticket and link to this one. Thanks! |
[REQUIRED] Describe your environment
[REQUIRED] Describe the problem
Steps to reproduce:
You need to import the package in a newly created next js application & run the application in the dev
Relevant Code:
The solution is to use the new version of node fetch in https://github.com/firebase/firebase-js-sdk/blob/master/packages/auth/package.json
The text was updated successfully, but these errors were encountered: