Repository navigation
Support of asynchronous computation in DefinePlugin.runtimeValue #16629
Description
Feature request
What is the expected behavior?
DefinePlugin.runtimeValue supporting async function / promise / callback for resolving value.
What is motivation or use case for adding/changing the behavior?
DefinePlugin.runtimeValue allow dynamic generation of define values and re-generation based on file-system changes.
Lack of async support means that
- If value is calculated from file contents they have to be read synchronously
- The processing can not use any library that provide exclusively async (promise/callback) api
- Blocking sequential operations will slow down the build
- Blocking operations will block the whole process which may be a big problem if webpack is as part of bigger program
How should this be implemented in your opinion?
I do not understand the code enough to suggest solution.
Are you willing to work on this yourself?
yes
Activity
alexander-akait commentedon Jan 13, 2023
Feel free to send a PR
TheLarkInn commentedon Mar 6, 2023
@AGrzes if you have questions or need guidance, don't hesitate to submit a draft PR, or follow up with @alexander-akait or myself in this issue.
webpack-bot commentedon Jun 5, 2023
This issue had no activity for at least three months.
It's subject to automatic issue closing if there is no activity in the next 15 days.
webpack-bot commentedon Jun 20, 2023
Issue was closed because of inactivity.
If you think this is still a valid issue, please file a new issue with additional information.
15 remaining items
evenstensberg commentedon Dec 29, 2024
https://webpack.js.org/plugins/define-plugin/#runtime-values-via-runtimevalue
gouravchahar13 commentedon Jan 24, 2025
sir should i send pr to main repository?
syhxzzz commentedon Jun 25, 2025
Hi,
I've been working on this PR and have some thoughts regarding asynchronous computations.
If we want to support asynchronous computation here, we'd need to declare fn as an async function where it's run in the source code, specifically in
lib/DefinePlugin.js, use await when calling it, and ensure the upstream functions are also async.However, this would lead to the "infectious" nature of asynchronous functions, where fn being async would force the top-level functions to also be async. I've noticed that the current design seems to assume these operations are synchronous. For example, consider the declaration for
evaluateIdentifier:These suggestions from @sepenlei may be right:
Therefore, if we were to support asynchronous operations, the declarations here would likely need to be redesigned. I'm also unsure if such changes would impact other modules.
If you believe this modification and line of thought are worthwhile, I'm willing to give it a try. However, before I proceed, I'd greatly appreciate your ideas on these proposed changes and the experimental approach.
neerajmaurya92084-ui commentedon Jul 16, 2026
// web-pack.config.js
const web-pack = require('web-pack');
module.exports = async (env, argv) => {
// 1. Perform your asynchronous computation out here
const asyncValue = await someAsyncCalculationOrFetch();
return {
// ... your standard webpack config ...
plugins: [
new webpack.DefinePlugin({
// 2. Pass the resolved static value directly
DYNAMIC_VALUE: JSON.stringify(asyncValue)
})
]
};
};
The cleanest workaround is to handle your asynchronous logic (like fetching an API or reading a file async) inside an asynchronous Web-pack configuration factory function. Web-pack natively supports exporting a Promise or an async function from you
LeonxLJX commentedon Sep 2, 2026
I'd like to take this one.
I've read through the report. Before changing anything I'd like to reproduce it against current
mainfirst — my reasoning is that a fix anchored to the actual observed behavior is much easier to review than one inferred from the report alone, especially if the surrounding code has moved since this was filed.Plan: reproduce and confirm the root cause, then make the smallest change that addresses it (plus a regression test if the repo has coverage for this area). If the root cause turns out to live somewhere other than where the report points, I'll report back here before forcing a change.
Anything already known about this that I should read first?
(claiming via @LeonxLJX)
shiv07-blip commentedon Sep 18, 2026
Hi @LeonxLJX just a quick check-in: you mentioned about two weeks ago that you'd like to take this one and would reproduce it against current
mainfirst. Are you still planning to work on it? If you're not able to pick it up right now, I'd be happy to take it over from here. Thanks!feat(DefinePlugin): resolve an async runtimeValue before parsing (web…