A Marko plugin and loader for Webpack.
@marko/webpack/loader
The loader portion of this module can be used standalone and simply transforms your Marko templates into the appropriate JavaScript depending on your webpack target.
You can override the output by adding a target
option to the loader of target: "server" | "browser"
.
@marko/webpack/plugin
The plugin actually creates two separate webpack plugins, the browser
plugin and the server
plugin.
These are intended to be used in a isomorphic webpack multi compiler where you are bundling both the server and the browser. The way it works is that the server plugin is going to analyze the top level Marko components in your server and automatically communicate with the browser compiler to retrieve the assets for that template.
This plugin also analyzes the top level Marko templates and determines if it is possible for them to rerender (currently the heuristic is simply does the component have an associated class
or component.js
). The plugin will automatically skip sending down any unnecessary top level templates to the browser.
The end result is that you setup a multi compiler (as shown below) and you can simply import Marko templates, and all assets are automatically generated and inlined into an optimized server response. No need to keep track of a webpack manifest yourself!
<webpack-assets>
The <webpack-assets>
tag can be used along with the plugin in a multi-compiler setup. This tag allows you to inject <script>
/<style>
tags into a server-rendered template for the assets of an entry in the client compiler.
<webpack-assets entry="tracking"/>
// ...
export default [
{
entry: "./server.js",
plugins: [markoPlugin.server]
// ...
},
{
// ...
entry: {
tracking: "./tracking.js"
},
plugins: [markoPlugin.browser]
}
];
@marko/webpack
>= 7 Only supports Marko 5+. For Marko 4 support use@marko/webpack@6
.
npm install @marko/webpack
import MarkoPlugin from "@marko/webpack/plugin";
const markoPlugin = new MarkoPlugin();
export default [
{
entry: "./server.js",
module: {
rules: [
{
test: /\.marko$/,
loader: "@marko/webpack/loader"
}
]
},
plugins: [markoPlugin.server]
},
{
rules: [
{
test: /\.marko$/,
loader: "@marko/webpack/loader"
},
// If using `style` blocks with Marko you must use an appropriate loader
{
test: /\.css$/,
use: ["style-loader", "css-loader"]
}
],
plugins: [markoPlugin.browser]
}
];
If you are using Marko 5 with this plugin you can manually override the Babel configuration used by passing a babelConfig
object along side the @marko/webpack/loader
. By default Babels regular config file resolution will be used.
export default {
module: {
rules: [
{
test: /\.marko$/,
loader: "@marko/webpack/loader",
options: {
babelConfig: {
presets: [
["@babel/preset-env", { node: "current" }]
]
}
}
}
]
}
},
Sometimes you need to have multiple compilers for your client side bundles. For example with i18n
or even shipping dynamic runtime bundles to the browser.
The Marko webpack browser plugin can be passed to multiple webpack compilers. At runtime you can provide a $global.buildName
when rendering which will cause assets from the webpack compiler with that name to be included in the page.
For example with the webpack i18n plugin you might have a config like the following:
import MarkoPlugin from "@marko/webpack/plugin";
import I18nPlugin from "i18n-webpack-plugin";
const languages = {
en: null,
de: require("./de.json")
};
const markoPlugin = new MarkoPlugin();
export default [
{
name: "Server",
entry: "./server.js",
module: {
rules: [
{
test: /\.marko$/,
loader: "@marko/webpack/loader"
}
]
},
plugins: [markoPlugin.server]
},
...Object.keys(languages).map(language => ({
name: `Browser-${language}`,
rules: [
{
test: /\.marko$/,
loader: "@marko/webpack/loader"
},
// If using `style` blocks with Marko you must use an appropriate loader
{
test: /\.css$/,
use: ["style-loader", "css-loader"]
}
],
plugins: [new I18nPlugin(languages[language]), markoPlugin.browser]
}))
];
With the above config you can render your top level Marko template server side with a $global.buildName
, like so:
template.render({ $global: { buildName: "Browser-de" } });
This will automatically send assets for the German language. Of course in this case you'll want to conditionally send the appropriate assets given a users locale. This can be some simply, like so:
template.render({ $global: { buildName: `Browser-${req.language}` } });
Note: If a bundle with the provided name does not exist an error will be thrown.
In some cases you may want to embed multiple isolated copies of Marko on the page. Since Marko relies on some window
properties to initialize this can cause issues. For example, by default Marko will read the server rendered hydration code from window.$components
. In Marko you can change these window
properties by rendering with { $global: { runtimeId: "MY_MARKO_RUNTIME_ID" } }
as input on the server side.
This plugin exposes a runtimeId
option produces output that automatically sets $global.runtimeId
on the server side and initializes properly in the browser.
The runtimeId
will default to the uniqueName
option from the server compiler in the webpack config.
import MarkoPlugin from "@marko/webpack/plugin";
const markoPlugin = new MarkoPlugin({
runtimeId: "MY_MARKO_RUNTIME_ID" // default to webpack `output.uniqueName` option.
});
Note: This option will also override the default values for the jsonpFunction
, chunkCallbackName
and hotUpdateFunction
webpack output
options, which all use global variables, to be prefixed with the runtimeId
.
When using the plugin, the server will automatically sync the runtime __webpack_public_path__
with the browser.
This means that you only need to setup the dynamic public path on the server side.
This project adheres to the eBay Code of Conduct. By participating in this project you agree to abide by its terms.