[RFC] Basic Deployment Solution For Modern.js #5663
Replies: 5 comments 16 replies
-
Will we build platform-related code into the framework or provide plugins? |
Beta Was this translation helpful? Give feedback.
-
Where is the html files, in the |
Beta Was this translation helpful? Give feedback.
-
So, when we exec |
Beta Was this translation helpful? Give feedback.
-
Why not just bundle the |
Beta Was this translation helpful? Give feedback.
-
OK that great..So the conclusion:
|
Beta Was this translation helpful? Give feedback.
-
Summary
The purpose of this proposal is to provide deployment support for Modern.js.
This RFC is a basic solution for deployment, and solutions for different platforms and runtime environments will be extended based on this solution.
Usage
We will provide a new
deploy
command:When this command is executed, the framework will detect the deployment platform and outputs the corresponding production output.
Also, developers can specify the currently deployed platform by an environment variable:
Multi-platform Support
As shown in the figure, we will continue to adjust the server-related code to make it platform-independent as much as possible, for different runtime environments, the framework will generate different entries for adaptation.
Structure Of Production Output
As you can see below,
index.js
is the generated entry for the different platforms.Production Dependencies
We have a deployment solution in the company, but the handling of dependencies is challenging for users, with the following issues:
@modern-js/prod-server
is not a direct dependency of the project, we had to add a phantom dependency.pnpm
,rush
), we need to make different adaptations.There are some ways to handle dependencies for deployment:
rsbuild
to bundle our server in the future, but there will still be some dependencies that need to be external.)deploy
solution provided by the monorepo tools(such aspnpm
,rush
), but there are the following problems:node_modules
directory of the output by the framework(by copying and creating symbolic links).In the past, we used a combination of the second and third approaches and pruned the dependencies, which brought up the above problems, so I prefer the last solution.
The following is a basic example of the last approach:
bar
is a dependency offoo
, and there are multiple versions of the bar in the project.utils
is a workspace package that is depended on by the currently deployed project.->
means a symbolic linkDetails
Compared with package managers, our scenario can be much simpler, so we don't need to write a package manager, here are the specific ways:
Firstly, the framework will trace all dependencies.
For the handling of dependencies, the framework will follow the following rules:
node_modules
directory.node_modules/.modernjs
directory, the newer version of package will be hoisted to top level ofnode_modules
and and each package will be created a symbolic link to its parent'snode_modules
.node_modules
directory uniformly. For dependencies of workspace packages, handle them according to the rules above.Finally, generate a new
package.json
based on the originalpackage.json
and dependency information.Limitations
.bin
directory.@vercel/nft
), and there are some dynamically required packages that we can't resolve, so we need to provide a configuration to include some dependencies in later version.Beta Was this translation helpful? Give feedback.
All reactions