Build FAQ
If you encounter any build-related issues, you can refer to the current document for troubleshooting.
Rsbuild FAQ
Modern.js is internally based on Rsbuild and encapsulates its own build tool, so you can directly refer to the FAQ document of Rsbuild:
How to view the final generated Rspack configuration?
Modern.js provides inspect command to view the final Modern.js configuration and Rspack configuration generated by the project.
Failed import other modules in Monorepo?
Due to considerations of compilation performance, by default, the Modern.js does not compile files under node_modules or files outside the current project directory.
Therefore, when you reference the source code of other sub-projects, you may encounter an error similar to You may need an additional loader to handle the result of these loaders.
There are several solutions to this problem:
- You can enable the source code build mode to compile other sub-projects within the monorepo. Please refer to Source Code Build Mode for more information.
- You can add the
source.includeconfiguration option to specify the directories or modules that need to be additionally compiled. Please refer to Usage of source.include for more information. - You can pre-build the sub-projects that need to be referenced, generate the corresponding build artifacts, and then reference the build artifacts in the current project instead of referencing the source code.
Find exports is not defined runtime error?
If the compilation is succeed, but the exports is not defined error appears after opening the page, it is usually because a CommonJS module is compiled by Babel.
Under normal circumstances, Modern.js will not use Babel to compile CommonJS modules. If the source.include configuration option is used in the project, some CommonJS modules may be added to the Babel compilation.
There are two workarounds for this problem:
- Avoid adding CommonJS modules to Babel compilation.
- Set Babel's
sourceTypeconfiguration tounambiguous.
Compile error "Error: ES Modules may not assign module.exports or exports.*, Use ESM export syntax"?
If the following error occurs during compilation, it is usually because a CommonJS module is compiled with Babel in the project, and the solution is same as the above exports is not defined problem.
For more information, please refer to issue: babel#12731.
The compilation progress bar is stuck, but there is no Error log in the terminal?
When the compilation progress bar is stuck, but there is no Error log on the terminal, it is usually because an exception occurred during the compilation. In some cases, when Error is caught by the build tool or other modules, the error log can not be output correctly. The most common scenario is that there is an exception in the Babel config, which is caught by the build tool, and the build tool swallows the Error in some cases.
Solution:
If this problem occurs after you modify the Babel config, it is recommended to check for the following incorrect usages:
- You have configured a plugin or preset that does not exist, maybe the name is misspelled, or it is not installed correctly.
- Whether multiple babel-plugin-imports are configured, but the name of each babel-plugin-import is not declared in the third item of the array.
Compilation error after referencing a type from lodash
If the @types/lodash package is installed in your project, you may import some types from lodash, such as the DebouncedFunc type:
Modern.js will throw an error after compiling the above code:
The reason is that Modern.js has enabled the babel-plugin-lodash plugin by default to optimize the bundle size of lodash, but Babel cannot distinguish between "value" and "type", which resulting in an exception in the compiled code.
The solution is to use TypeScript's import type syntax to explicitly declare the DebouncedFunc type:
In any case, it is recommended to use import type to import types, this will help the compiler to identify the type.