Usage of polyfill configuration throws error #10010
Comments
jeluard
added
bug
|
Hi
I'm not sure to follow, why exactly? How is this different from using external dependencies in React page components? How are external dependencies requiring a node polyfill different from first-party code you write that requires the exact same polyfill?
It's not clear from which version you are upgrading exactly. If it didn't work before, then how can we consider the new v3.2 breaks things?
I don't know either. A minimal repro showing exactly the code to polyfill would help. It's not us that recommended usage of This repro is not very actionable from my perspective. I can't investigate your monorepo in its entirety to look for problems because it's not minimal and many things on it could be the source of problems (for example, a dependency/hoisting problem related to the package manager) Please create a minimal repro using https://docusaurus.new/stackblitz I need to see a minimal project that works on a specific version before the upgrade, despite including a lib requiring polyfill. And I need to see it failing after the upgrade. |
slorber
added
status: needs more information
What is different is the way things are configured in docusaurus. How can I tweak webpack's configuration in docusaurus?
I can look at providing a minimal reproducing issue definitely. What is the recommended approach to hook polyfill, if any? Note that in dev mode (i.e. |
jeluard
changed the title
https://docusaurus.io/docs/api/plugin-methods/lifecycle-apis#configureWebpack
That would help me help you 👍
"very similar" does not help. If you have an error, please share it exactly as is. We don't have a recommended approach for now, because most sites don't need it and this is not different from any other Webpack app. If you can make it work outside Docusaurus, you can probably make it work similarly inside. I still don't even know what contains your code to require such polyfill. None of the 2 reported errors in this issue (v3.1 or v3.2) look related to polyfills.
Probably because the problem is due to using browser APIs in Node.js, which is likely not a polyfill issue. I will only be able to help if I see a minimal repro. |
|
You can find a minimal repository here. First commit just uses the lib w/o polyfill, then the second adds a polyfill.
This is what I did here by providing a plugin, so I would assume that this is the right approach.
Some libraries relies on node code (e.g.
That's the other way around, those libs use node APIs e.f. crypto or path. Historically browserify or others have been used to address that. I've seen a number of workaround in the wild, so looks like others people have those needs: |
slorber
removed
the
status: needs more information
|
I'm sorry but this repro is still not minimal to me. You don't even mention "the lib" that requires polyfills. The minimal repro should have the code requiring to polyfill inlined, so that we can focus on that, and solely that. Otherwise you are asking me to retro-engineer your Reading the error message, it's still not clear to me how you could be 100% convinced the problem is related to polyfills and nodejs APIs. That's why I want to see very simple code. Just add It's not clear to me why you use both resolve aliases/fallbacks in addition to the polyfill plugin you mentioned above. Why both at the same time? Is this how you are supposed to polyfill things? Also, do we finally agree that this is not particularly related to v3.2? Because you changed the title. BTW you should rather do this, otherwise, you risk polyfilling Node APIs that are already provided and override them. configureWebpack(config, isServer, utils) {
if (isServer) {
return;
} |
|
You are using this component inside your homepage:
import {useEffect, useState} from "react";
import {getClient} from "@lodestar/api";
import {createChainForkConfig} from "@lodestar/config";
import {networksChainConfig} from "@lodestar/config/networks";
import {Lightclient, LightclientEvent} from "@lodestar/light-client";
import {LightClientRestTransport} from "@lodestar/light-client/transport";
import {getFinalizedSyncCheckpoint, getGenesisData, getLcLoggerConsole} from "@lodestar/light-client/utils";
const config = createChainForkConfig(networksChainConfig.mainnet);
const logger = getLcLoggerConsole({logDebug: true});
const api = getClient({urls: ["https://lodestar-mainnet.chainsafe.io"]}, {config});
const lightclient = await Lightclient.initializeFromCheckpointRoot({
config,
logger,
transport: new LightClientRestTransport(api),
genesisData: await getGenesisData(api),
checkpointRoot: await getFinalizedSyncCheckpoint(api),
opts: {
allowForcedUpdates: true,
updateHeadersOnForcedUpdate: true,
},
});
await lightclient.start();
export function LatestOptimisticHeader(): React.JSX.Element {
const [head, setHead] = useState<string | undefined>();
const [updated, setUpdated] = useState<boolean>(false);
useEffect(() => {
lightclient.emitter.on(LightclientEvent.lightClientOptimisticHeader, (optimisticUpdate) => {
setHead(optimisticUpdate.beacon.slot.toString());
setUpdated(true);
setTimeout(() => setUpdated(false), 1000);
});
}, []);
return (
<span>
Latest optimistic header: <span className={updated ? "highlight" : ""}>{head}</span>
</span>
);
}Again, this is not minimal at all. You are expecting me to retro-engineer your code. The only thing I can tell you is that this has never worked in Docusaurus, not in v3.2 or any previous versions, simply because we don't support ESM and top-level await. As soon as you remove usage of this component, your Docusaurus site can build, so this code is the problem. I'm closing because I doubt there is a bug in Docusaurus. We'll re-open when a truly minimal repro is provided, not involving the complexity of your custom dependencies and the code above which can't work. |
slorber
added
the
closed: can't repro
Have you read the Contributing Guidelines on issues?
Prerequisites
npm run clearoryarn clearcommand.rm -rf node_modules yarn.lock package-lock.jsonand re-installing packages.Description
When writing mdx components using external dependencies, it might be necessary to use polyfills. One way to do that is to create a docusaurus plugin leveraging
node-polyfill-webpack-plugin.After migrating to docusaurus 3.2 an exception is thrown when building the final website.
Note: it's not clear to me if this is the recommended approach to polyfill node.
Reproducible demo
https://github.com/jeluard/lodestar/commit/41289518460a460810bf1f04efb76db782705f93
Steps to reproduce
cd docsyarnyarn buildExpected behavior
Compilation should finish and node specifics should be polyfilled.
Actual behavior
The following error is thrown:
Note that with docusaurus
3.1a different error is thrown.Your environment
Self-service
The text was updated successfully, but these errors were encountered: