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.
-
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
Plugin
trait that has many methods. The methods will be called in some special timing.Process
Create
Compiler
Compiler
First, we will create a
Compiler
and invokeCompiler#run()
to start the build process.Compiler
organized the whole process of bundling.Compiler
will create aCompilation
as the context of bundling to share some data.Build
ModuleGraph
Then, we will create
Dependency
s by the entry options user input.Dependency
Dependency
is a struct that describes a relation between modules(which module imports which module in what way).code
The
Dependency
will be transformed into theResolvingModuleJob
struct. By running theseResolvingModuleJob
s we start the process of building a module graph.ResolvingModuleJob
ResolvingModuleJob
is a struct that represents the process of resolvingModule
.In the
ResolvingModuleJob
URI
of the module through theDependency
.URI
URI
is the location of the source code. In most cases, theURI
is the disk path of the javascript file.URI
transform
hook of plugins to transform the source code.parse_module
hook to parse the source codeDependency
s.ModuleGraphModule
and store it inModuleGraph
.ModuleGraphModule
ModuleGraphModule
is a wrapper of the parsed result, the goal is to store some extra information the bundler cared about.ModuleGraph
ModuleGraphModule
stored modules and their relations. We could get aModuleGraphModule
fromModuleGraph
in multiple ways.ResolvingModuleJob
s are running in different threads, so we need to deal with concurrent programming. The bundler has a global counteractive_task_count
to memorize how manyResolvingModuleJob
s were created. When theactive_task_count
is 0, we think the building of theModuleGraph
is finished.Build
ChunkGraph
We will create basic
Chunk
s by entry module and dynamic import. The details are complicated. But the basic rules are quite intuitive.Chunk
Chunk
is 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
ChunkGraph
to plugins to do further optimization.Make
Asset
sAfter building
ChunkGraph
, we will expose eachChunk
to plugins by therender_manifest
hook to let plugins decide how and whatAsset
to generate.Asset
Asset
is 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