-
Notifications
You must be signed in to change notification settings - Fork 813
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
WebPack error: Critical dependency: the request of a dependency is an expression #4173
Comments
This is critical to the functioning of the instrumentation package and can't really be removed without causing other problems. Even if you get past this step, all node autoinstrumentations depend very heavily on There are definitely people using otel in webpack contexts so it is definitely possible, but I think the autoinstrumentations are unlikely to work and you'll have to jump through quite some hoops and/or use manual instrumentation. |
I'll close this for now. Overall, it makes sense for specific instrumentations to violate this rule - most of them won't be compatible with WebPack or any other pack in many cases. But it'd be good to keep it await from the the core library. |
Adding this note for posterity. Here's what the issue looks like in practice, with a work-around. What it looks like
A work-around: In my particular case, the root of this came from NextJS (which does a lot of server side rendering) trying to run client-side code in server-side pre-rendering. In
|
This is a mess. Help me @Vadman97. You're my only hope. Ignoring warnings because there's no solution: open-telemetry/opentelemetry-js#4173 (comment) ![image](https://github.com/highlight/highlight/assets/878947/458f2a2e-4f38-4fb9-a41f-2e8d55807cfe) ![image](https://github.com/highlight/highlight/assets/878947/8e1f5868-f0bd-42dd-b5a2-676295557421) --------- Co-authored-by: Vadim Korolik <[email protected]>
Just fyi, the particular error in this issue should be fixed with the release of #4593. It would be cool if we could get it actually released soon! |
@timfish @lforst Tried to use updated version of Should we resolve private _warnOnPreloadedModules(): void {
this._modules.forEach((module: InstrumentationModuleDefinition) => {
const { name } = module;
try {
- const resolvedModule = require.resolve(name);
- if (require.cache[resolvedModule]) {
+ if (require.cache[name]) {
// Module is already cached, which means the instrumentation hook might not work
this._diag.warn(
`Module ${name} has been loaded before ${this.instrumentationName} so it might not work, please initialize it before requiring ${name}`
);
}
} catch {
// Module isn't available, we can simply skip
}
});
} |
Sorry I missed that. It appears I only fixed one of the issues! The only quick fix I can think of is to hide the function resolveHiddenFromBundlers(
mod: { require: { resolve: (name: string) => string } },
name: string
): string {
return mod.require.resolve(name);
}
const resolvedModule = resolveHiddenFromBundlers(module, name); This is a common approach to hide There are some other less desirable approaches: |
+1 on the hiding solution. I believe the |
@lforst I agree. I've opened #4744 to start potentially adding bundler-related tests in this repo. Would you, @timfish, and/or others be able to help a bit on that? I grok the test infrastructure in the repo, but I don't know the bundlers that well at all. my failed attempt at a simple webpack repro of the aboveI have briefly tried -- and failed so far -- to repro the |
@trentm Happy to help out with build process! We happen to have experience with it and I think there's some room for improvement. btw: Your attempted repro is currently private. Would you mind turning it public? 😄 |
🤦 It is public now. |
If you are using NextJS 14.2, updating the packages to
|
FWIW, just updating those wasn't sufficient for me. I had to add |
In our Next.js v14 project, we were receiving these errors as well. They appeared after we upgraded Sentry from v7 to v8. Some of our files were importing directly from |
What happened?
Steps to Reproduce
Running
const sdk = new NodeSDK({}); sdk.start();
pops up this WebPack error:Expected Result
No error.
Actual Result
Error.
Additional Details
It appears that the error is coming from a dynamic import here:
opentelemetry-js/experimental/packages/opentelemetry-instrumentation/src/platform/node/instrumentation.ts
Line 164 in c84698d
It's even shielded by the
// eslint-disable-next-line @typescript-eslint/no-var-requires
.This seems like an auxiliary function and perhaps the SDK could allow users to bypass the need to execute this dynamic require?
OpenTelemetry Setup Code
package.json
Relevant log output
The text was updated successfully, but these errors were encountered: