Replies: 5 comments 2 replies
-
        (WIP)Data Structures
 | 
  
Beta Was this translation helpful? Give feedback.
-
| 
         we may need to support chunkGroup for future supporting bundle splitting  | 
  
Beta Was this translation helpful? Give feedback.
-
| 
         ResolvingModuleJob is nearly the same as NormalModuleFactory, I think we may stick to webpack's name  | 
  
Beta Was this translation helpful? Give feedback.
-
| 
         the finalize process is also important, whether we should take webpack's way or rollup's way?  | 
  
Beta Was this translation helpful? Give feedback.
-
| 
         we may need an architecture overview like https://github.com/evanw/esbuild/blob/master/docs/architecture.md#overview  | 
  
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
We want to make a bundler that has the following principles.
Productive means the bundler needs to consider real-world cases in any circumstances.
To achieve the goal of being productive, the bundler needs to be extensible to implement any features easily without huge changing in the codebase. Thus, the bundler will have a robust plugin system.
Performant means the bundler could handle the real-world cases scalably.
General
The bundler has two parts. The core and plugin system.
The core
The responsibilities of the core are
That is it. These are the critical points of the core in bundler.
Plugin system
The plugin system is still in the design, but the basic idea is that the bundler will provide a
Plugintrait that has many methods. The methods will be called in some special timing.Process
Create
CompilerCompilerFirst, we will create a
Compilerand invokeCompiler#run()to start the build process.Compilerorganized the whole process of bundling.Compilerwill create aCompilationas the context of bundling to share some data.Build
ModuleGraphThen, we will create
Dependencys by the entry options user input.DependencyDependencyis a struct that describes a relation between modules(which module imports which module in what way).code
The
Dependencywill be transformed into theResolvingModuleJobstruct. By running theseResolvingModuleJobs we start the process of building a module graph.ResolvingModuleJobResolvingModuleJobis a struct that represents the process of resolvingModule.In the
ResolvingModuleJobURIof the module through theDependency.URIURIis the location of the source code. In most cases, theURIis the disk path of the javascript file.URItransformhook of plugins to transform the source code.parse_modulehook to parse the source codeDependencys.ModuleGraphModuleand store it inModuleGraph.ModuleGraphModuleModuleGraphModuleis a wrapper of the parsed result, the goal is to store some extra information the bundler cared about.ModuleGraphModuleGraphModulestored modules and their relations. We could get aModuleGraphModulefromModuleGraphin multiple ways.ResolvingModuleJobs are running in different threads, so we need to deal with concurrent programming. The bundler has a global counteractive_task_countto memorize how manyResolvingModuleJobs were created. When theactive_task_countis 0, we think the building of theModuleGraphis finished.Build
ChunkGraphWe will create basic
Chunks by entry module and dynamic import. The details are complicated. But the basic rules are quite intuitive.ChunkChunkis a set that contains a series of modules. The type of modules could be different. For example, A chunk could also include javascript modules and CSS modules.In the end, we will expose the
ChunkGraphto plugins to do further optimization.Make
AssetsAfter building
ChunkGraph, we will expose eachChunkto plugins by therender_manifesthook to let plugins decide how and whatAssetto generate.AssetAssetis a struct that represents a file in RSpack that going to be emitted.In the end, the bundler will emit these assets to dist. And the whole process is finished.
Beta Was this translation helpful? Give feedback.
All reactions