Currently conditions are fixed in build.initialOptions – however, it would be useful in certain situations to modify these dynamically as certain modules are resolved.
One example of this is React, which has started using the react-server condition to compile modules for RSC rendering – and provides different resolutions of, say, the react module depending on whether the react-server condition is present. This currently makes it impossible to compile a bundle that uses the react-server and non-react-server resolved react module for different parts of the code (eg, some code wishes to render using RSC and some doesn't).
If build.resolve could take conditions as an option, then at least a plugin could be written that could compile some portion of the code using one condition (eg, all code under ./rsc/... gets compiled with the react-server condition), and the rest without.
Currently
conditionsare fixed inbuild.initialOptions– however, it would be useful in certain situations to modify these dynamically as certain modules are resolved.One example of this is React, which has started using the
react-servercondition to compile modules for RSC rendering – and provides different resolutions of, say, thereactmodule depending on whether thereact-servercondition is present. This currently makes it impossible to compile a bundle that uses thereact-serverand non-react-serverresolvedreactmodule for different parts of the code (eg, some code wishes to render using RSC and some doesn't).If
build.resolvecould takeconditionsas an option, then at least a plugin could be written that could compile some portion of the code using one condition (eg, all code under./rsc/...gets compiled with thereact-servercondition), and the rest without.