New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial exploration of startService API #4484
base: master
Are you sure you want to change the base?
Conversation
I think this has a lot of potential, will have a deeper look later this week. |
ensureModule(module: Module | ExternalModule) { | ||
// Make sure that the same module / external module can only be added to the | ||
// graph once since it may be requested multiple times over the life of a | ||
// service. | ||
const modules: Array<Module | ExternalModule> = | ||
module instanceof Module ? this.modules : this.externalModules; | ||
|
||
if (!modules.includes(module)) { | ||
modules.push(module); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just convert this.modules
to a Set
instead of doing this, should also have better performance for large bundles. We are mostly iterating over them, which works just as well for a Set
, and it is a private variable anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eca6a6c
to
71d20c9
Compare
cbd94e6
to
f1538ce
Compare
This PR contains:
Are tests included?
Not yet
Breaking Changes?
List any relevant issue numbers:
N/A - Experimental feature exploration
Description
This PR is designed to add a new operating paradigm ('service mode') to Rollup to allow it to fulfill the requirements of tools like Vite and WMR's dev mode such that those tools can use Rollup directly instead of re-implementing parts of it that are specific to the dev workflow.
To be useful to tools like Vite, I extrapolate the following top-level requirements (but would love it if others can fine-tune this):
Bundle
withpreserveModules
andpreserveEntrySignatures
set tostrict
orallow-extension
. For example, this might be used to translate an http request for a source file into code suitable for serving to the browser. It might also be used to create a dynamic Node module usable in the same wayViteDevServer::ssrLoadModule
is used in Vite.Plugin
has usedemitFile
to produce a new asset (or module), the application must be able to determine if the requested asset exists and obtain a reference to it. For example, a dev server would want to distinguish between urls it controls and404
s. If the Rollup Service has an asset at the requested path, then that is a 'controlled' url and the app would want to serve the asset owned by Rollup.manualChunks
where the app could indicate that it wants to treatreact
as a black-box. The app would ask Rollup to traverse the graph and include everything within the app-defined boundary (in this case./node_modules/react
) in a single output unit. The app might say that a user's source files should be1:1
with output artifacts but a users's dependencies would ben:1
.I suspect that Rollup has almost all of the essential bits to satisfy these requirements but that it would take some refactoring. I expect that the change of paradigm from run-to-completion to also supporting a long-lived, incremental service would be tricky. Assumptions about internal state at different phases of the pipeline might be broken. To attack this problem will mean finding those and coming up with strategies to support re-entrancy.
The hardest parts that I anticipate are related to invalidation tracking. Specifically, invalidation of module resolution. To support this sort of invalidation would require the cooperation of module-resolution plugins and perhaps new APIs in Rollup's Plugin Context to support tracking changes to the contents (or existence of) directories. Invalidating internal state will also expose a lot of assumptions about statefulness.
Having talked through a lot of this with @lukastaegert at a high level on Discord, we think that tree-shaking (as a concept) would be counter-productive to the effort. Perhaps this Service mode would force disable tree-shaking.
We also talked about how to deal with some conventions that would affect performance in real-world use-cases, such as those for which Vite is designed. Notably, libraries like
react
use theprocess.env.NODE_ENV
convention to package both dev and production builds in the same module. A tool using the Service mode of Rollup would want to be able to build plugins that could prune branches of the AST based on this convention and have graph building reflect this.Thoughts?