Ideas for dealing with external dependencies #360
Comments
|
Rolldown is a bundler with similar functionalities as rollup, but written in Rust which means we can directly use it into our backend. It is not yet stabilized thus not published to crates.io (rolldown/rolldown#3227), but we can directly depend on its git source. This will only prevent our crates from being published, but it is almost certain that rolldown gets stabilized before Deskulpt does so not a problem. Widget Developers' SideRolldown has built-in support for node modules resolution so external dependencies is not a problem for widget developers who are assumed to have node and thus let bundler_options = BundlerOptions {
input: Some(vec!["WIDGET_CONFIG.ENTRY".to_string().into()]),
cwd: Some(WIDGET_CONFIG.DIR),
format: Some(OutputFormat::Esm),
// This also has some additional handling of e.g. `process.env.NODE_ENV` so that we will not
// need plugin-replace as with rollup
platform: Some(Platform::Browser),
// This is still experimental
minify: Some(true),
// Enable checks so we do not miss warnings
checks: Some(ChecksOptions { circular_dependency: Some(true) }),
// Assume that we have `react` and `@emotion/react/jsx-runtime` re-exported, so they can be
// treated as external (not resolved when bundling)
external: Some(
vec![
"BASE_URL/.scripts/react".to_string(),
"BASE_URL/.scripts/@emotion/react/jsx-runtime".to_string(),
]
.into(),
),
// Use the automatic JSX runtime with source from `@emotion/react` so it will finally resolve
// to `@emotion/react/jsx-runtime` which is treated as external
jsx: Some(Jsx::Enable(JsxOptions {
runtime: JsxRuntime::Automatic,
import_source: Some("@emotion/react".to_string()),
..Default::default()
})),
..Default::default()
}
let alias_plugin = AliasPlugin {
entries: vec![
// Alias both `react/jsx-runtime` and `@emotion/react/jsx-runtime` to the externalized
// local script so they can share what's used by the Deskulpt runtime; IIRC the JSX
// runtime of `@emotion/react` is a superset of `react` (it just in addition supports
// the `css` attribute) so this should be safe
Alias {
find: StringOrRegex::String("react/jsx-runtime".to_string()),
replacement: "BASE_URL/.scripts/@emotion/react/jsx-runtime".to_string(),
},
Alias {
find: StringOrRegex::String("@emotion/react/jsx-runtime".to_string()),
replacement: "BASE_URL/.scripts/@emotion/react/jsx-runtime".to_string(),
},
// Alias `react` to the externalize local script; note that the order matters, i.e.,
// this aliasing must happen after the `react/jsx-runtime` one, otherwise `react`
// will be aliased to `BASE_URL/.scripts/react` first and the runtime will be resolved
// to `BASE_URL/.scripts/react/jsx-runtime` which does not exist
Alias {
find: StringOrRegex::String("react".to_string()),
replacement: "BASE_URL/.scripts/react".to_string(),
},
],
}
let bundler = Bundler::with_plugins(bundler_options, vec![Arc::new(alias_plugin)]);Widget Developer PackagingIn the previous design of #66 with SWC and rollup, the packaging step is mixed with the normal bundling routing with external dependencies. It may make more sense to keep these as separate processes. The packaging step would be producing a
Note It is actually arguable whether tree-shaking should be performed or not. If no tree-shaking, the bundle size might be significantly larger, but users would be able to use whatever is in that external dependency, regardless of whether the widget has used some item or not when distributed. If tree-shaking, the bundle size would be kept minimal, but if users would not be able to use items that the original widget did not use, even if they exist in that external dependency (they would need node in this case). The following assumes that we still wants tree-shaking. We will definitely ship A small benchmark that may or may not be correct: including the whole
|
This issue is for tracking ideas for dealing with widget external dependencies.
High-level goals are:
The text was updated successfully, but these errors were encountered: