![\"Image\"](\"https://lume.land/uploads/lume-old.png\")
So, you thought that Lume could only generate static sites, right?
\nNot anymore! As of version 3.2, Lume can also create books in EPUB\nformat. That's why I wanted to dedicate this version to one of the most\nimportant figures of Galician literature of all time: RosalĆa de Castro.
\n\nYou may know RosalĆa, the popular\nSpanish singer. But in Galicia, we have another RosalĆa:\nRosalĆa de Castro,\nprobably our most important poet and novelist. She was a leading figure in the\nperiod of the resurgence and revitalization of the Galician language in\nliterature during the 19th century (period known as\nRexurdimento).
\nSome of her poems were set to music by several artists. Do you want an example?\nEnjoy\n"Negra sombra" (black shadow)\ninterpreted by Luz Casal.
\nepubEPUB is the standard format for ebooks.\nTechnically, it's a zip file containing files in formats like XHTML, CSS, JPEG,\nPNG; and other xml files specific for ebooks (a container.xml manifest file, a\ncontent.opf with the book structure, etc). Robin Whittleton\nwrote a great article\nexplaining how EPUB works.
Since EPUB is based on web standards that Lume understands, it seems feasible to\nuse Lume to create EPUBs. The only problem was the requirement of\nXHTML (HTML is not valid for EPUBs), and this\nwasn't easy to do in previous versions of Lume. But in this version, Lume can\noutput .xhtml files and treat them in the same way as .html, hence we also\nhave an EPUB plugin to help you to generate EPUBs. What this plugin can do?
container.xml, encryption.xml, mimetype, and content.opf\nmanifest files.toc.ncx file with the book structure (using the\nnav plugin under the hood)..html pages to .xhtml.book.epub file in the dest folder.This is an example of using the plugin:
\nimport lume from "lume/mod.ts";\nimport epub from "lume/plugins/epub.ts";\n\nconst site = lume({\n prettyUrls: false, // prettyUrls don't make sense for ebooks\n});\n\nsite.use(epub({\n // Book metadata\n metadata: {\n identifier: "unique identifier of your book",\n cover: "/images/cover.png",\n title: "My awesome book",\n subtitle: "History of my life",\n creator: ["Ćscar Otero"],\n publisher: "Lume editions",\n language: "en-US",\n date: new Date("2026-01-31T12:18:28Z"),\n },\n}));\n\nexport default site;\nNote that the plugin cannot magically convert any website to an EPUB; you still\nneed to have a proper structure, use some epub specific attributes, etc. But\ndon't worry! the Simple ePub theme\nprovides a nice boilerplate to start publishing books.
\nLearn more about this plugin\non the documentation page.
\nimage_sizeThis is a recurrent request, and finally, Lume has a plugin to add automatically\nthe width and height values of the images.
The plugin uses the awesome\nimage-dimensions library by\nSindre Sorhus. To use it, just install it like any other plugin:
\nimport lume from "lume/mod.ts";\nimport imageSize from "lume/plugins/image_size.ts";\n\nconst site = lume();\n\nsite.use(imageSize());\n\nexport default site;\nAdd the image-size attribute to the images you want the plugin to calculate\nthe size:
<img src="/image.png" image-size>\nAnd the plugin automatically adds the width and height attributes:
<img src="/image.png" width="600" height="300">\nMore info on the documentation page.
\nextract_orderSometimes you have a list of pages that you want to show in a specific order. A\ncommon way to do that is to define an order variable in the front matter:
---\ntitle: Article 3\norder: 3\n---\n\nThis is the article 3\nThen, you only have to select the pages in this specific order:
\n{{ set pages = search.pages("type=article", "order=asc") }}\nThis works great, the only problem is that you can't see the pages in the same\norder in your code editor or file system because they are ordered\nalphabetically:
\n/article-three.md\n/first-article.md\n/other-article.md\nWith this plugin you can set the order in the filename, using the format\n{number}.filename, and this value will be used as the order variable. The\nplugin also removes this prefix from the final URL by default (configurable).
/1.first-article.md\n/2.other-article.md\n/3.article-three.md\nThis also works great for folders:
\n/1.articles/\n 1.first-article.md\n 2.other-article.md\n 3.article-three.md\n/2.notes/\n 1.note-one.md\n 2.note-two.md\nTo use it:
\nimport lume from "lume/mod.ts";\nimport extractOrder from "lume/plugins/extract_order.ts";\n\nconst site = lume();\n\nsite.use(extractOrder());\n\nexport default site;\nMore info on the documentation page.
\nreplaceThis simple plugin allows to perform simple text replacements in the site,\nsomething especially useful for documentation sites. For example, let's say you\nwant to display always the last version of your library in a website:
\nWelcome to Libros 2.3.0, the library to read ebook. To getting started, run the\nfollowing command:\n\ndeno install --global https://deno.land/x/libros@2.3.0/mod.ts\nInstead of harcoding the version number everywhere in your site (and remember to\nupdate it after a new version), this plugin allows to use a placeholder:
\nWelcome to Libros $VERSION, the library to read ebook. To getting started, run\nthe following command:\n\ndeno install --global https://deno.land/x/libros@$VERSION/mod.ts\nNow, configure the replacements in the plugin options:
\nimport lume from "lume/mod.ts";\nimport replace from "lume/plugins/replace.ts";\n\nconst site = lume();\n\nsite.use(replace({\n replacements: {\n "$VERSION": "2.3.0",\n },\n}));\n\nexport default site;\nNow you have this value centralized in one place. This is the approach used in\nthe Lume website to\nkeep the versions of all packages up to date.
\nYou can use this plugin for any constant value that you want to use globally,\nlike a query parameter for caching CSS and JS files, the hash of the latest\ncommit, the year in the copyright, etc.
\nMore info on the documentation page.
\nparseBasename can access the parent valuesThe function\nsite.parseBasename allows\nregistering functions to extract values from files and folders. In fact, it's\nwhat the extract_order and extract_date plugins use under the hood.
As of Lume 3.2, the data from the parent folder is added as the second argument.\nThis allows us to compose values contextually using the names of different\nfolders. For example, let's say we have some files with the following paths:
\n/2026/01/01/happy-new-year.md\n/2026/01/05/this-year-sucks.md\nNow you can compose the final date of each file using the values of the\ndirectories and subdirectories. For example:
\nsite.parseBasename((basename, parent) => {\n // Check if the name only contains numbers\n if (!/^\\d+$/.test(name)) {\n return;\n }\n\n // 4 digits, it's the year\n if (basename.length === 4) {\n return { year: basename, basename }\n }\n\n // 2 digits, it's the month or day\n if (basename.length === 2) {\n // If the month isn't in the parent, this is the month\n if (!parent.month) {\n return { month: basename, basename }\n }\n\n // This is the day, generate the final date\n const { year, month } = parent;\n return {\n date: `${year}`-${month}`-${basename}`,\n basename,\n }\n }\n})\nwatcher.dependencies optionThe Lume file watcher detects changes in your files in order to rebuild the site\nwith the new content. An important aspect is that only the changed files are\nreloaded, which is way faster than reloading all files every time something\nchanged. This works great in 99% of the cases, but there are some edge cases\nwhere we need to say Lume to reload a file when another file has changed.
\nAs an example, let's say you have some data stored in a SQLite database and you\nwant to expose some of its data to your pages using a _data.ts file:
// _data.ts\nimport { DatabaseSync } from "node:sqlite";\n\nconst db = new DatabaseSync("database.db");\n\nexport const categories = db.prepare(`\n SELECT\n categories.id,\n categories.name\n FROM categories\n`).all();\n\ndb.close();\nAs you can see, we are exporting the categories variable, and this will make\nit available to all pages. If we make changes in the database.db file, Lume\nwill detect that the file has changed, but because _data.ts hasn't changed,\nLume won't re-run this file, so the new changes won't be available. What we\nreally want is to reload the _data.ts file every time the database.db file\nhas changed. And now we can do it thanks to the new watcher.dependencies\noption:
import lume from "lume/mod.ts";\n\nconst site = lume({\n watcher: {\n dependencies: {\n "_data.ts": ["database.db-journal"],\n },\n },\n});\n\nexport default site;\nHere we are telling Lume that the file _data.ts depends on\ndatabase.db-journal (the extension .db-journal is used by SQLite to create a\ntemporary file during the data transactions). Now Lume knows that every time any\nof its dependencies change, _data.ts will be reloaded too.
When Lume builds a site, the logger outputs messages to the terminal in the same\norder they are generated. One problem with this approach is that there are\nmessages more important than others, and, especially if the site has a lot of\npages, those messages can be lost among others. Another problem is that if the\nsame error is produced by different pages, it's shown once per page, which\nproduces a lot of noise and prevents seeing other important messages. Let's see\nan example:
\nWARN [esbuild plugin] No TS, JS, TSX, JSX files found. Use site.add() to add files. For example: site.add("script.js")\nERROR SourceError: Unclosed tag\n/_includes/templates/blocks.vto:4:3\n 1 | {{ for block of blocks }}\n 2 | {{ if !block.hide }}\n 3 | {{ await comp[block.type]({ block, lang, url }) }}\n 4 | {{ /if }\n | ^ Unclosed tag\nERROR SourceError: Unclosed tag\n/_includes/templates/blocks.vto:4:3\n 1 | {{ for block of blocks }}\n 2 | {{ if !block.hide }}\n 3 | {{ await comp[block.type]({ block, lang, url }) }}\n 4 | {{ /if }\n | ^ Unclosed tag\nš„ /docs/configuration/env-variables/ <- /docs/configuration/env-variables.md\nš„ /docs/configuration/config-file/ <- /docs/configuration/config-file.md\nš„ /docs/configuration/add-files/ <- /docs/configuration/add-files.md\nš„ /img/extend.svg <- /img/extend.svg\nš„ /img/deploy.svg <- /img/deploy.svg\n...\nš„ /img/http-imports.svg <- /img/http-imports.svg\nš„ /init.ts <- /static/init.ts\nš„ /img/gradient.png <- /img/gradient.png\nš„ /img/zero-runtime.svg <- /img/zero-runtime.svg\nš„ /logo.png <- /static/logo.png\nWARN [validate_html plugin] 512 HTML error(s) found. Setup an output file or check the debug bar.\nWARN [seo plugin] 45 SEO error(s) found. Setup an output file or check the debug bar.\nš¾ Site built into ./_site\n 188 files generated in 6.28 seconds\nIn the example, the Vento error shown twice because it occurred on two pages.\nThere are some WARN errors at the start and others at the end, and a long list\nof generated pages in the middle.
\nIn order to make the logs clearer, two changes were introduced in this version\nof Lume:
\nThe example above is shown as follows in the new version:
\n...\nš„ /img/http-imports.svg <- /img/http-imports.svg\nš„ /init.ts <- /static/init.ts\nš„ /img/gradient.png <- /img/gradient.png\nš„ /img/zero-runtime.svg <- /img/zero-runtime.svg\nš„ /logo.png <- /static/logo.png\nš¾ Site built into ./_site\n 188 files generated in 6.28 seconds\nWARN [validate_html plugin] 512 HTML error(s) found. Setup an output file or check the debug bar.\nWARN [seo plugin] 45 SEO error(s) found. Setup an output file or check the debug bar.\nWARN [esbuild plugin] No TS, JS, TSX, JSX files found. Use site.add() to add files. For example: site.add("script.js")\nERROR SourceError: Unclosed tag\n/_includes/templates/blocks.vto:4:3\n 1 | {{ for block of blocks }}\n 2 | {{ if !block.hide }}\n 3 | {{ await comp[block.type]({ block, lang, url }) }}\n 4 | {{ /if }\n | ^ Unclosed tag\nThis hopefully ensures that you won't miss anything important during the build\nprocess!
\nThis version also includes some minor changes and several bugfixes. Some of\nthem:
\nkatex plugin supports mhchem extension and includes an option to disable\nthe download of CSS and fonts.date filter registered by date plugin detects the language of the\ncurrent page.script.ts file, it no longer conflicts with the script.js\nfile generated by components.Finally, I'd like to thank all contributors for helping make Lume so great with\nPR or supporting the project with sponsoring and donations. š«¶
\n","date_published":"Mon, 09 Feb 2026 00:00:00 GMT"},{"id":"https://lume.land/blog/posts/new-logo/","url":"https://lume.land/blog/posts/new-logo/","title":"Lume has a new logo!","content_html":"Lume was born 5 years ago as an excuse to try Deno, the new JavaScript runtime.\nAt that moment, the hype around Deno led to many projects featuring a dinosaur\nin their logo. Lume joined this trend, making a joke with the concept of fire\nand Deno.
\n\n
I've wanted to change the logo for a long time, and finally, I could manage some\ntime to work on that. There are many reasons for this change:
\nFor the new logo, I wanted to focus on the main concept of Lume: the fire. I\ndidn't want to create yet another logo with a flame. Instead, I still wanted a\npet, but a firefly instead of a dinosaur.
\nInterestingly enough, in Galician, a firefly is called vagalume, which makes\nsense for a project called Lume.
\nThe new logo is more geometric, created with a leaf shape repeated five times,\nand a head with two antennae. This simple design makes it work better at small\nsizes.
\n![\"Image\"](\"https://lume.land/uploads/logo-outline.png\"){kind=logo}
The red color is used to represent the fire that emits light (using a gradient).\nIt also works in dark and light contexts, just inverting the black and white\ncolors:
\n![\"Image\"](\"https://lume.land/uploads/logo-negativo.png\"){kind=logo}
![\"Image\"](\"https://lume.land/uploads/logo-positivo.png\"){kind=logo}
The font family used didn't change. It's still\nEpilogue, a\nbeautiful sans-serif font with a great x-height. I only made some kerning tweaks\nand the name is now "Lume" (with upper case L) instead of "lume".
\nThanks to JosĆ© Luis AntĆŗnez for the feedback and\nsuggestions, and to Studio Ghibli for the film\nGrave of the Fireflies\nfrom which I got some inspiration.
\n","date_published":"Wed, 05 Nov 2025 00:00:00 GMT"},{"id":"https://lume.land/blog/posts/lume-3-1-0/","url":"https://lume.land/blog/posts/lume-3-1-0/","title":"Lume 3.1.0 - Alexandre BĆ³veda","content_html":"The first minor version of Lume 3 is dedicated to\nAlexandre BĆ³veda, a\nfinancial officer and politician who was executed on 17 August 1936 by Franco's\ndictatorship because of his Galician ideals. The night before his death, he\nwrote three farewell letters, the last one to his brother:
\n\n\n[...] I will die peacefully; I trust that I will be received where we all want\nto get together, and I do it with joy and entrust to God this sacrifice. I\nwanted to do good, I worked for Pontevedra, for Galicia, and for the Republic,\nand the flawed judgment of men (which I forgive and you all must forgive)\ncondemns me.
\nBe more of a man now than ever because this is when you should be the most,\nfor our elderly and for the children, to whom, without expecting it, you are\ngoing to be a little father. Comfort them all and try to always be good. Don't\nregret how much good you have done and can still do. [...]
\n
Alexandre is not only a Galician martyr but also a demonstration that there have\nalways been good people in the world. Now, more than ever, we have to remember\nthat.
\n\nFor the past 5 years, Lume's main distribution channel has been\ndeno.land/x, the CDN created by Deno to distribute\npackages using HTTP imports. This package registry has been deprecated in favor\nof JSR, a new registry that doesn't support HTTP. Since Deno\ndoesn't want people to use deno.land/x (as indicated in the two\nbig yellow banners in the page to add new modules)\nand migration to JSR is not an option, we decided to switch to a different CDN.
jsDelivr is the obvious choice for many reasons:
\nLume will still be published on deno.land/x; the only difference is that the\nscript to update or initialize a new Lume project will choose jsDelivr by\ndefault. That's one of the many benefits of using HTTP imports: its\ndecentralized nature allows you to change the CDN at any moment with zero\nimpact.
deno.json fileDeno added some great improvements to deno.json in recent versions that Lume\nhas adopted for the init and upgrade script:
lume task uses bare specifierDeno 2.4 added\nsupport for bare specifiers in deno run.\nIn older versions, the only way to use a specifier defined in the import map was\nusing deno eval or the ugly:
{\n "tasks": {\n "lume": "echo \\"import 'lume/cli.ts'\\" | deno run -A -"\n }\n}\nBut now, this is supported:
\n{\n "tasks": {\n "lume": "deno run -A lume/cli.ts"\n }\n}\nlume tasks have descriptionsTo improve the UX, the tasks created by Lume include a description. Run\ndeno task to see all available tasks with the description:
{\n "tasks": {\n "lume": {\n "description": "Run Lume command",\n "command": "deno run -A lume/cli.ts"\n },\n "build": {\n "description": "Build the site for production",\n "command": "deno task lume"\n },\n "serve": {\n "description": "Run and serve the site for development",\n "command": "deno task lume -s"\n }\n }\n}\nDeno 2.5\nallows to configure permissions in the deno.json file,\nand Lume adopted this nice feature. Now you have the lume permission preset\nthat is used when running the lume task (previously, it used the -A flag,\nwhich disables the permissions). This will improve the security of your builds\nand will make it easy to edit the permissions to adapt to your needs. This is\nthe default configuration:
{\n "permissions": {\n "lume": {\n "read": true,\n "write": [\n "./"\n ],\n "import": [\n "cdn.jsdelivr.net:443",\n "jsr.io:443",\n "deno.land:443",\n "esm.sh:443"\n ],\n "net": [\n "0.0.0.0",\n "jsr.io:443",\n "cdn.jsdelivr.net:443",\n "data.jsdelivr.com:443",\n "registry.npmjs.org:443"\n ],\n "env": true,\n "run": true,\n "ffi": true,\n "sys": true\n }\n }\n}\nAs you can see, Deno only has writing permissions for the current folder, net\npermissions to localhost (to run the local server), and net and import\npermissions for JSR, NPM, esm.sh and JsDelivr (to import dependencies). The\nother permissions are granted by default because they are needed for some\nplugins, but you can edit this configuration to make it more restrictive or\nrelaxed.
\nOne of the main challenges with LumeCMS has been integrating it smoothly with\nLume or other static site generators. Previously, LumeCMS relied on Hono to\nrun both the CMS and the page preview, which could lead to inconsistencies: a\npage served by Lume (deno task serve) might differ from one served by LumeCMS,\nsince Hono's static server doesn't exactly match Lume's. For example,\nmiddlewares configured for Lume are not available in the CMS, and this affects\nfeatures like live reload, debugbar, etc.
With version 0.13, LumeCMS introduces\nsignificant changes. Now, LumeCMS is\na middleware on top of Lume's server, handling only requests that start with\n/admin/* while delegating page previews to Lume's server. This makes the\nintegration easier, eliminating the need for separate commands\n(deno task serve and deno task cms).
This means that the cms task was removed. Just run deno task serve and,\nif the _cms.ts file is present, the CMS is automatically initialized.
When LumeCMS is running on a VPS, it requires two processes:
\nThe main process starts the secondary process on demand and works as a reverse\nproxy. This allows restarting Lume and LumeCMS after some changes (for example,\nwhen updating the changes with git pull or after changing the git branch)\nwithout closing the server.
Until now, you needed to use\nan external package to setup it. Now\nit's much easier since Lume's main repo includes a module to run the CMS in\nproduction: You only need to run deno serve -A lume/serve.ts and that's all!!
validate_htmlThis plugin checks the HTML code of your site and validates it using\nhtml-validate, a fast NPM package that works\noffline.
\nThe plugin was originally\ncreated by dish\nand now it's an official Lume plugin, integrated with the Debug bar and with\ndifferent options to export the report.
\nThe easiest way to use it is to import it into the _config.ts file:
import lume from "lume/mod.ts";\nimport validateHtml from "lume/plugins/validate_html.ts";\n\nconst site = lume();\nsite.use(validateHtml());\n\nexport default site;\nNow you will see a new tab in the Debug bar with all HTML errors detected in the\nsite:
\n![\"Image\"](\"https://lume.land/uploads/debugbar_validate_html.png\")
I hope this plugin will help you to create more standard and bug-free websites.
\npartytownPartytown is a JavaScript library to run\nthird-party scripts in a web worker. The goal is to dedicate the main thread to\nyour code, and move other resource-intensive third-party scripts, like analytics\nor tracking services to a different thread, making the website faster and more\nsecure.
\nThe plugin was created originally\nby kwaa 2 years ago\nas an experimental plugin, and now it has moved to the main repo. To use it, you\nhave to register it in the _config.ts file:
\nimport lume from "lume/mod.ts";\nimport partytown from "lume/plugins/partytown.ts";\n\nconst site = lume();\nsite.use(partytown());\n\nexport default site;\nAnd now add the type="text/partytown" attribute to all scripts that you want\nto run from the web worker:
<script type="text/partytown">...</script>\nseoThis plugin was created by Tim Post with the\nhelp of Rick Cogley for the Japanese language\nsupport (thanks so much, guys!). It's a really interesting plugin that not only\ncan check the SEO basics (titles, descriptions, alt text in images, etc) but\nalso other not very common checks like common words percentage.
\nSince Tim couldn't maintain it, we decided to port it to the Lume repo and\nconvert it to an "official plugin". It was modified in order to align with the\nstyle and conventions of other plugins, and it was simplified a bit to make it\nmore maintainable in the long run (originally, the project was more ambitious).
\nThe installation is not different from other plugins, just import it into the\n_config.ts file:
\nimport lume from "lume/mod.ts";\nimport seo from "lume/plugins/seo.ts";\n\nconst site = lume();\nsite.use(seo());\n\nexport default site;\nLike other validator plugins (check_urls, validate_html, etc), it creates a\nnew tab in the debug bar with all SEO issues found in all pages. It also has an\noption to export the report to a JSON file or any other format by providing a\ncustom export function.
The plugin is highly customizable. The default options are enough for most\ncases, but you can change how to validate titles, H1 tags, meta descriptions,\nheading orders, duplicated titles, etc. Definitely, this plugin will help you to\ncreate more successful websites!
\nThe function remoteFile allows\nthe use of URLs to download the content of a file if it doesn't exist locally.\nFor example:
site.remoteFile("/styles/styles.css", "https://example.com/styles/styles.css");\nIf the file /styles/styles.css doesn't exist locally, the content of the URL\nwill be used in place. This is very useful for themes because it allows for\nplacing all templates and styles used by a theme remotely.
The only problem with this function is that it only works for single files. If\nyou have several files, you need to call the function once per file:
\nconst files = [\n "styles.css",\n "components/button.css",\n "components/alert.css",\n "components/icons.css",\n];\n\nfor (const file of files) {\n site.remoteFile("/styles/" + file, "https://example.com/styles/" + file);\n}\nsite.remote() functionLume 3.1 includes the new function site.remote() similar to\nsite.remoteFile() but allows to register more than one file:
const files = [\n "styles.css",\n "components/button.css",\n "components/alert.css",\n "components/icons.css",\n];\n\nsite.remote("/styles/", "https://example.com/styles/", files);\nOkay, you may think this isn't a big improvement, it's just a bit simpler. But\nthe good news is that you can use some specifiers that are compatible with glob\npatterns:
\nnpm: to use NPM packages (like npm:lucide-static@0.544.0)gh: to use GitHub repositories (like gh:lumeland/theme-simple-wiki)file: to use local fileshttps://cdn.jsdelivr.net/.For example, let's say the CSS files are stored in a GitHub repository:
\nconst files = [\n "/styles/**/*.css",\n];\n\nsite.remote("/styles/", "gh:username/repo@tag", files);\nThat's better now! Under the hood, this is possible thanks to the API of\nJsDelivr. Any compatible specifier is converted to JsDelivr equivalent.
\nFor example, gh:lumeland/theme-simple-wiki@0.14.3 is converted to\nhttps://cdn.jsdelivr.net/gh/lumeland/theme-simple-wiki@0.14.3/.\nAnd using the JsDelivr API, we can know the paths of all files in the repository\n(example),\nso we can filter them using the glob pattern.
Thanks to this new function, it's easier to create Lume themes, since you don't\nhave to worry about forgetting to include a new file that was recently created.\nLet's see this example:
\nconst themeFiles = [\n "/_includes/**",\n "/*.css",\n "/*.js",\n "/*.vto",\n];\n\nsite.remote("/", import.meta.resolve("./"), themeFiles);\nIn local development, import.meta.resolve("./") resolves to a file://...\nurl, so the glob patterns work great. If this package is published and imported\nfrom JsDelivr, it's resolved to https://cdn.jsdelivr.net/gh/user/repo@tag, and\nthe glob patterns are still supported thanks to the JsDelivr API. This is\nanother reason to recommend distributing Deno packages on JsDelivr over\ndeno.land/x.
Note
\nFor backward compatibility, the function site.remoteFile is still available\nas an alias of site.remote, for example, site.remoteFile(local, remote) is\nan alias of site.remote(local, remote).
As of Lume 3.1, the inline plugin not only\nprocesses HTML files but also CSS. This allows for inlining background images\neasily. To use it, just append the ?inline parameter to the file URL. For\nexample:
.warning {\n background-image: url("/icons/warning.svg?inline");\n}\nIs converted to:
\n.warning {\n background-image: url("data:image/svg+xml;utf8,<svg...</svg>");\n}\nUntil now, the picture plugin has only\nallowed the width value to resize images. For example, this configuration\ntransforms the image to 300px and 600px, with versions for 2x resolutions and\nformats AVIF, WebP, and JPG:
\n<img src="/flowers.jpg" transform-images="avif webp jpg 300@2 600@2">\nNow it's possible to specify a height to crop the images to a specific aspect\nratio:
\n<img src="/flowers.jpg" transform-images="avif webp jpg 300x150@2 600x300@2">\nThe image will be cropped to 300x150 and 600x300, with a version for 2x\nresolutions. For now, there isn't any way to configure the origin of the crop\n(it's always centered), but this option can be added in future versions.
\nSee\nthe CHANGELOG.md file\nto see a complete list of all changes.
\n","date_published":"Fri, 17 Oct 2025 00:00:00 GMT"},{"id":"https://lume.land/blog/lume-cms-0-13/","url":"https://lume.land/blog/lume-cms-0-13/","title":"Lume CMS 0.13.0","content_html":"It's been a while (one and a half year!) since\nLumeCMS was announced as an alternative to other existing\nCMS to edit the content of websites.
\nDuring this time, the project was improved in many ways: more field formats,\nmore customization options, light/dark mode, etc.
\nBut, like many projects in their earlier phases, LumeCMS was a bit "tricky" to\nrun. It was created as a framework-agnostic solution, but in practice, it wasn't\neasy to set up for other frameworks than Lume.
\nVersion 0.13 has received a lot of changes in order to address this issue, among\nothers. Some of these changes are BREAKING CHANGES (hopefully they are only a\nfew). And even though it's still a development version (the version starts with\nv0.* yet), I think it's an important step towards the future v1.0 version.
Since the beginning, LumeCMS has used Hono under the hood.\nAlthough Hono is a very powerful and popular framework, I found it a bit\ncomplicated to work with. The way to pass data (or contexts) to routers and\nmiddlewares, the rendering system or the use of the custom class HonoRequest\nfor the request instead of the standard Request (that is also available but\nhidden) made me spend more time trying to figure out how to do something in\n"Hono way" than just doing it. In addition to that, it's becoming a\nfull-featured framework with even a client-side JSX library.
That's why Galo was created. It's a fast\nand minimalist router that embraces web standards and simplicity without\nsacrificing flexibility. The change from a framework approach to a library like\nthis made LumeCMS much easier to embed in any application running Deno. In fact,\nLumeCMS is now a middleware for your application without any side effects or\ninterference with your existing code.
\n![\"Image\"](\"https://lume.land/uploads/lumecms-galo.png\")
LumeCMS was created assuming that all data would be stored in an object. Let's\nsee this example:
\ncms.collection({\n name: "notes",\n storage: "src:notes/*.json",\n fields: [\n "title: text",\n "text: textarea",\n ],\n});\nThis stores every note in a JSON file in the notes/ directory. The stored\nnotes have a structure like this:
{\n "title": "Note title",\n "text": "This is the note"\n}\nIf you want to store all notes in a single JSON file, you can use an\nobject-list field to store an array of objects:
cms.document({\n name: "notes",\n storage: "src:notes.json",\n fields: [\n {\n name: "notes",\n type: "object-list",\n fields: [\n "title: text",\n "text: textarea",\n ],\n },\n ],\n});\nThis configuration produces the following data structure:
\n{\n "notes": [\n {\n "title": "First note",\n "text": "Text of the first note"\n },\n {\n "title": "Second note",\n "text": "Text of the second note"\n }\n ]\n}\nAs you can see, the root of the data is still an object with the notes\nproperty to hold the array of notes. But what we really want is to store the\narray of notes as the root element. Until now, the solution was to change\nthe name of the root value from notes to []:
cms.document({\n name: "notes",\n storage: "src:notes.json",\n fields: [\n {\n name: "[]",\n type: "object-list",\n fields: [\n "title: text",\n "text: textarea",\n ],\n },\n ],\n});\nLumeCMS detected the special name "[]" as an instruction to ignore the element\nand store its content directly. This allows us to store the data as an array:
\n[\n {\n "title": "First note",\n "text": "Text of the first note"\n },\n {\n "title": "Second note",\n "text": "Text of the second note"\n }\n]\nThe problem with this solution is that it's a bit hacky, verbose, and not very\nflexible. That's why in version 0.13 this feature was replaced with the new\ntype option:
cms.document({\n name: "notes",\n storage: "src:notes.json",\n type: "object-list",\n fields: [\n "title: text",\n "text: textarea",\n ],\n});\nAs you may guess, this option configures the field type used to store the root\ndata. If it's not defined, the default value is object, but other available\nvalues are object-list (to store an array of objects) and choose (to allow\nthe user to choose one structure among a list of options). More types can be\nadded in future versions.
previewUrl and sourcePath optionsOne of the great features of LumeCMS is the ability to preview the changes while\nediting the data. To provide this, we need two things:
\n/posts/hello-world.md produces the URL /posts/hello-world/, we can\ndisplay this URL in the preview panel when the file is being edited./posts/hello-world/ is generated by /posts/hello-world.md, we can create a\n"Edit this page" link to go directly to the edit form.Until now, the way to get this info was a bit obscure and undocumented. In\nversion 0.13, this is fully configurable, which makes the CMS easier to adapt\nfor other static site generators:
\nconst cms = lumeCMS({\n previewUrl(path: string, content: Lume.CMS.Content, changed: boolean) {\n // Return the URL generated by this file\n },\n sourcePath(url: string, content: Lume.CMS.Content) {\n // Return the file path that generates this URL\n }\n});\nThe previewUrl is also customizable at the document or collection level,\nuseful if you're editing a file that doesn't directly produce a URL but can\naffect it (like a _data file):
cms.document({\n name: "Common data",\n storage: "src:_data.yml",\n previewUrl: () => "/", // preview the homepage\n fields: [\n "title: text",\n "description: textarea",\n ],\n});\nIn previous versions, you could configure the permissions to create, edit,\nrename, or delete documents globally. For example, let's say we have a\ncollection of countries that we don't want to remove or create new ones, just\nedit them:
\ncms.collection({\n name: "countries",\n storage: "src:countries/*.json",\n fields: [\n "name: text",\n "description: textarea",\n ],\n create: false,\n delete: false,\n rename: false,\n});\nWith this configuration, all users can edit the countries, but cannot create,\ndelete, or rename files. In version 0.13.0, we can override this configuration\nfor some users:
\ncms.auth({\n user1: {\n password: "password1",\n name: "Admin",\n permissions: {\n "countries": {\n create: true,\n delete: true,\n rename: true,\n },\n },\n },\n user2: "password2",\n});\nIn previous versions, the auth configuration was simply an object with names and\npasswords. Now, we can also use an object to include more options. In this\nexample, the "user1" has a password, the name "Admin" (which is used to show it\nin the interface instead of "user1"), and some special permissions that override\nthe permissions assigned to documents and collections: this user can create,\nrename, and delete files of the countries collection, unlike "user2".
\ndocumentLabelIf you see the list of documents in a collection, LumeCMS only displays the file\nnames. Since it doesn't load the documents data, it can't use any value inside\nthem (like title or date properties). The option documentLabel allows\ncustomization of how this document is shown in the interface. For example, it\ncan transform the name my-first-post.md to a more human My First Post. In\nfact, LumeCMS comes with this especific behavior by default, but you can\ncustomize it with your own tranformer:
cms.collection({\n documentLabel: (filename) => filename.replace(".json", ""),\n // More options...\n});\nAs of version 0.13, this function can return an object with the properties\nlabel, icon, and flags to extract and show more info in the list view.
Let's say our collection of countries is a folder with the following files:
\n/en-spain.json\n/pt-portugal.json\n/fr-france.json\n/it-italy.json\nWe can configure the collection to show only the country name, and use the flag\nicon (from Phosphor) instead of the default\ndocument icon. The country code is the code is saved in the flags object:
\ncms.collection({\n documentLabel: (filename) => {\n const [code, name] = filename.replace(".json", "").split("-");\n return {\n label: name,\n icon: "flag"\n flags: { code }\n }\n },\n // ...more options\n});\nrelation and relation-list fieldsThis feature is related to the improvements on documentLabel explained above.\nNow that we can extract more info from the filename, we can use this info to\nlink a document to another. For example, let's say we have the "people"\ncollection and we want to assign a country to each person:
cms.collection({\n name: "people",\n storage: "src:people/*.md",\n fields: [\n "name: text",\n {\n name: "country",\n type: "relation",\n\n // The collection name that we want to relate\n collection: "countries",\n\n // A function to return a label and value for each option\n option: ({ label, flags }) => { label, value: flags.code }\n }\n ]\n});\nNow, this field shows a selector to pick one of the countries and use the code\nflag as the value (en for Spain, pt for Portugal, etc). The relation-list\nfield is similar but allows for storing an array of values.
The git commits created by LumeCMS now include the current user name as the\nauthor. It's also possible to include the email by adding the email property\nto the user settings:
cms.auth({\n user1: {\n password: "password1",\n\n // name & email are included in the commits created by this user.\n name: "Admin",\n email: "user@example.com",\n },\n});\nNow it's possible to configure a document without fields, to show a code editor\ninstead of a form to edit it. It's useful to edit code directly from the CMS:
\ncms.document({\n name: "Custom styles",\n storage: "src:style.css",\n});\nFrom now on, date and datetime fields don't include the timezone in the YAML\nfiles. Hopefully, it will fix a lot of problems related to unexpected dates due\nto different time zones.
\n# before\ndate: 2025-01-11T00:00:00.000Z\n\n# after\ndate: 2025-01-11 00:00:00\nThere are more changes in this version, like UI improvements, ability to show\nEXIF data from uploaded images, the new cssSelector option to highlight an\nelement in the previewer related with a field, etc.
Take a look at the\nCHANGELOG.md file\nto see the complete list of changes.
\nThis version isn't compatible with Lume 3.0.x, but it will be in Lume 3.1.
\nIf you want to try it, upgrade Lume to the latest development version with:
\ndeno task lume upgrade --dev\nThen, run deno task serve and the CMS is automatically created if a _cms.ts\nfile is detected. You won't need to run deno task cms anymore!
![\"Vento](\"https://lume.land/uploads/vento-2.svg\")
Vento was born two years ago as an experiment to create a modern, ergonomic, and\nasync-friendly template engine for JavaScript. Initially, it was a Deno-only\nproject, intended to become the default template engine for Lume. But as\nsoon as the NPM package was available,\nother projects started to use it.
\n\nDuring this period, a number of people got involved in the development.
\n{{ somevariable }} instead of\n{{ it.somevariable }}. She's also responsible for the\ntree-sitter parser to bring\nsupport for Neovim and similar editors.Vento wouldn't be so awesome without the help of these contributors and\nmany other that improve\nit with their selfless work. THANK YOU SO MUCH!
\nEverything started with\nthis post where\nvrugtehagel exposed some issues detected in Vento. He was kind enough to send me\nan email to let me know about the post whose constructive feedback was very\nhelpful and several issues mentioned were addressed in Vento 1.
\nHowever, vrugtehagel not only limited himself to providing feedback, but he also\nstarted to get involved in the\nSublime Text plugin and created a\nbunch of\npull requests to the Vento repository,\nleading to some interesting discussions about Vento's philosophy and its\nimplementation approach. The most demanding challenge, for which we made\ndifferent proofs of concept, was to find an alternative way to analyze the\nJavaScript code without using meriyah or any other dependency. This would make\nthe compilation faster and remove all Vento dependencies.
\nThanks to this change, the local footprint was reduced from 1.8MB to less than\n80Kb (18KB bundled and minified).
\nThe next step was to convert Vento in an isomorphic library, which makes it to\nwork on browsers and on Node-like runtimes (Node, Deno, Bun) without changes or\nthe need for a compilation step.
\nAnd finally, one of the pain points of Vento, error reporting, was also\naddressed thanks to the\ninitial work of vrugtehagel and\nsome subsequent changes by me.
\nVento is now a modern, lean, and powerful template engine that can be used on\nany JavaScript runtime and embedded on any framework easily.
\nAfter upgrading to Vento 2, almost everything in your .vto files should continue\nworking as usual without changes, although there might be some edge cases that\nnow have a different behavior.
\nIn Vento 1, when you run Hello {{ name }}, the compiler converts it\nautomatically to Hello {{ it.name }}. This means that, technically, you\ncould define a variable directly in the it global variable and it would be\naccessible without the prefix. For example, the following code would print\n"Hello World":
{{> it.name = "World" }}\nHello {{ name }}\nVento 2 uses a different approach. When Vento compiles the following template:
\nHello {{ name }}\nall variables used are initialized preventively at the begining like this:
\nvar { name } = it;\nThe variable is not replaced with it.name automatically everywhere but the\nreal variable name is created instead. If you edit the value of it.name in\nyour code directly, it won't affect name. However, this is more a Vento's\ninternals change and it's unlikely to affect to final users since they never\nshould edit the it variable directly, but use the code\n{{ set name = "other value" }}.
Any error produced while compiling or running the templates is now converted to\na VentoError class. This class contains all the information required to report\nthe exact point where the error originates. For example, the following template\nproduce an error because we are invoking a function from a null variable:
{{ set name = null }}\n{{ name.foo() }}\nIn order to run and pretty-print errors, you can use the printError helper:
import vento from "vento/mod.ts";\nimport { printError } from "vento/core/error.js";\n\nconst env = vento();\n\ntry {\n const result = await env.run("my-template.vto");\n} catch (err) {\n console.error(await printError(err));\n}\nThis outputs the following:
\nTypeError: Cannot read properties of null (reading 'foo')\ntest/main.vto:2:1\n 1 | {{ set name = null }}\n 2 | {{ name.foo() }}\n | ^\n | __exports.content += (name.foo()) ?? "";\n | ^ Cannot read properties of null (reading 'foo')\nThe error displays the tag where the error occurs and it can show also the error\nin the compiled code (the final JavaScript code) to give more context.
\nNote that the error handler doesn't work consistently accross all runtimes, due\ntheir differences providing useful data from the error stack. For example, it\nworks pretty well on Deno, but Node and Bun cannot recover the exact location of\nsome errors so it's not possible to provide detailed info in some cases. There\nmay be also some differences between browsers.
\nI hope this feature can be improved in next versions. PR are very appreciated!
\nVento is async by default, it's one of its main selling points. In Vento 1\nthere was also the function runStringSync to run arbitrary code in a\nsynchronous context. For example:\nenv.runStringSync("Hello {{ name }}", { name: "World"}).
This mode was originally created because Lume needed it. However, the\nsynchronous mode doesn't fit well with how Vento works internally. Having both\nsync and async modes makes everything more complicated, and the sync mode breaks\nif your template has async tags, like {{ include }}, or runs any async\nfunction or filter.
Since Lume no longer needs this feature, the function was removed in Vento 2,\nand now all templates are run consistently in an async context.
\nslot tagThe layout tag allows to render a\ntemplate passing extra content. This is great for layouts expecting only one\npiece of content. But if the layout requires more pieces, you have to pass them\nas variables:
{{ layout "article.vto" { header: "<h1>This is the title</h1>" } }}\n <p>This is the content</p>\n{{ /layout }}\nThe new slot tag allows to capture and store the content in different\nvariables, similar to what web components do.
{{ layout "article.vto" }}\n {{ slot header }}\n <h1>This is the title</h1>\n {{ /slot }}\n\n <p>This is the content</p>\n{{ /layout }}\nLearn more about\nslots in the documentation site.
\nAs said, Vento 2 works also on browsers, without any compilation step, thanks to\nnot having dependencies and the use of standard APIs. You can download the NPM\npackage or use a CDN like jsDelivr:
\nimport vento from "https://cdn.jsdelivr.net/npm/ventojs@2.0.0/web.js";\n\nconst env = vento({\n includes: import.meta.resolve("./templates"),\n});\n\nconst result = await env.run("main.vto");\nconsole.log(result.content);\nNote that instead of importing the mod.js module, you have to import web.js.\nThe only difference is that web.js uses the URL loader by default to load\ntemplates using fetch. The includes option defines the base URL to load all\ntemplates.
Vento 1 was already quite fast, but version 2 is even faster thanks to the new\ncompiler.
\nThe compiler in Vento 2 is almost 200% faster as you can see in the\nfollowing benchmark:
\n| Compilation | \ntime/iter (avg) | \niter/s | \n
|---|---|---|
| Vento 2 | \n196.0 Āµs | \n5,102 | \n
| Vento 1 | \n378.0 Āµs | \n2,646 | \n
When comparing the rendering performance of Vento 1 and Vento 2, there are no\nsignificant differences. Vento 1 may be slightly faster, but the difference is\nminimal and not easily noticeable.
\n| Rendering | \ntime/iter (avg) | \niter/s | \n
|---|---|---|
| Vento 2 | \n860.9 ns | \n1,162,000 | \n
| Vento 1 | \n820.0 ns | \n1,220,000 | \n
Comparing compilation and rendering performance, Vento 2 demonstrates a 180%\nspeed improvement. Even if a few milliseconds are lost during rendering, the\noverall performance gain more than compensates for it.
\n| Comp. & rendering | \ntime/iter (avg) | \niter/s | \n
|---|---|---|
| Vento 2 | \n186.0 Āµs | \n5,376 | \n
| Vento 1 | \n342.8 Āµs | \n2,917 | \n
To compare the performance of Vento with other template engines, you can\nrun the bench code in\nVento's repository. As of writing this post, the benchmark data is:
\n| Compilation | \ntime/iter (avg) | \niter/s | \n
|---|---|---|
| 1. Eta | \n51.1 Āµs | \n19,580 | \n
| 2. EJS | \n145.2 Āµs | \n6,888 | \n
| 3. Vento | \n196.0 Āµs | \n5,102 | \n
| 4. Nunjucks | \n602.1 Āµs | \n1,661 | \n
| 5. Liquid | \n635.0 Āµs | \n1,575 | \n
| 6. Preact | \n978.4 Āµs | \n1,022 | \n
| 7. Pug | \n4.2 ms | \n237 | \n
| Rendering | \ntime/iter (avg) | \niter/s | \n
|---|---|---|
| 1. Vento | \n860.9 ns | \n1,162,000 | \n
| 2. Pug | \n1.6 Āµs | \n632,100 | \n
| 3. Preact | \n8.8 Āµs | \n113,900 | \n
| 4. Eta | \n11.2 Āµs | \n89,600 | \n
| 5. EJS | \n14.8 Āµs | \n67,790 | \n
| 6. Liquid | \n351.3 Āµs | \n2,847 | \n
| 7. Nunjucks | \n812.5 Āµs | \n1,231 | \n
| Comp. & rendering | \ntime/iter (avg) | \niter/s | \n
|---|---|---|
| 1. Eta | \n68.0 Āµs | \n14,700 | \n
| 2. EJS | \n177.3 Āµs | \n5,639 | \n
| 3. Vento | \n186.0 Āµs | \n5,376 | \n
| 4. Edge | \n518.0 Āµs | \n1,931 | \n
| 5. Preact | \n706.5 Āµs | \n1,415 | \n
| 6. Liquid | \n1.1 ms | \n937 | \n
| 7. Nunjucks | \n1.5 ms | \n676 | \n
| 8. Pug | \n4.2 ms | \n236 | \n
Vento delivers exceptional rendering performance. While Eta and EJS offer faster\ncompilation speeds, they struggle with delimiter handling. For example,\n<%= '%>' %> throws an error in EJS, but Vento handles the equivalent,\n{{ '}}' }}, perfectly fine.
Vento 2 is available on NPM (for Node-like runtimes) and HTTP imports (for\nbrowsers and Deno). See the\nCHANGELOG file for\nthe full list of changes.
\n","date_published":"Mon, 01 Sep 2025 00:00:00 GMT"},{"id":"https://lume.land/blog/posts/lume-3/","url":"https://lume.land/blog/posts/lume-3/","title":"Lume 3 was released - Adolfina CasƔs","content_html":"After launching Lume 2 almost a year and a half ago, a new major version of Lume\nis here!
\n![\"Adolfina](\"https://lume.land/uploads/adolfina-casas.jpeg\")
This version is dedicated to all Galician cantareiras and\npandereteirasāwomen who sing and play the tambourine (or pandeireta), one of\nthe most important instruments in Galician traditional music. One of these\ncantareiras was Adolfina CasĆ”s Rama (1912-2009), an ancestor of my friend Miriam\nCasĆ”s. She worked in agriculture, where she often sang. She was known for her\nwit and the variety of styles employed.
\nThanks to the recollidas, where musicians and musicologists recorded these\ntraditional songs sung by anonymous women, we can now enjoy this musical\nheritage performed by contemporary musicians with innovative arrangements.
\nSome examples include\nXabier DĆaz & Adufeiras de Salitre,\nXosĆ© Lois Romero & Aliboria, and\nBerrogĆ¼etto (apologies for the\nvideo quality, but I really love that song).
\nFor more disruptive artists, check out\nTanxugueiras or\nBaiuca.
\n\nTo many developers, including myself, breaking changes can be frustrating.\nSoftware updates that force you to revisit a project just to ensure it continues\nworking as before often feel like a waste of time. This is one of the reasons I\nenjoy working with Web APIsāthey are stable, reliable, and designed to just work\nwithout introducing unnecessary disruptions.
\nI strive to bring a similar philosophy to Lume by minimizing breaking changes\nwhenever possible. In fact, I initially had no plans to release a new major\nversion of Lume. However, after receiving numerous reports about certain\nbehaviors and limitations, I realized it was necessary to revisit some design\ndecisions. This effort aims to finally deliver the simple, intuitive static site\ngenerator I have always envisioned, hoping that Lume 4 won't be necesary in a\nlong time, or never.
\nNote
\nTL/DR: There's\na step-by-step guide to migrate to Lume 3\nin the documentation.
\nThe site.copy() function allows you to copy files from the src folder\nwithout reading the content, which is faster and consumes less memory. But it\nhas one big drawback: the files are not processed.
For example, let's say you have the following configuration:
\nsite.copy("/assets");\nsite.use(postcss());\nWhen Lume builds your site, the files inside the /assets folder are copied\nas-is. If the folder contains CSS files, they won't be processed by Postcss.\nLearn more about\nthis issue on GitHub.
This behavior is confusing and many people reported this as a bug. And they are\nright: Lume should be clever enough to not delegate the decision of whether a\nfile must be loaded or copied.
\nsite.add()In Lume 3, the site.loadAssets(), site.copyRemainingFiles() and\nsite.copy() functions were removed, and now there is a single function for\neverything: site.add().
The add() function simply tells Lume that you want to include some files in\nyour site, but without specifying how this file must be treated. Lume will load\nthe file if it needs to (for example, if it needs to be processed), or will copy\nit if no transformations are needed.
site.add("/assets");\nsite.use(postcss()); // CSS files in /assets will be processed too!\nTo upgrade from Lume 2 to Lume 3, just replace the site.loadAssets(),\nsite.copyRemainingFiles(), and site.copy() functions with site.add().
For example:
\n// Lume 2\nsite.loadAssets([".css"]);\nsite.copy("/assets", ".");\nsite.copyRemainingFiles(\n (path: string) => path.startsWith("/articles/"),\n);\n\n// Lume 3\nsite.add([".css"]);\nsite.add("/assets", ".");\nsite.add("/articles");\n\n\nUpdate: Some users have reported that
\nsite.copy()remains useful in\nspecific scenarios. For instance, if you need to copy a CSS file without\nprocessing it. As a result, thesite.copy()function was reintroduced in\nLume 3.0.1 to address these edge cases.
site.add() can add files from the src folder as well as remote files. In\nLume 2, this was possible with the remoteFile function:
// Lume 2\nsite.remoteFile("styles.css", "https://example.com/theme/styles.css");\nsite.copy("styles.css");\nLume 3 makes this use case easier:
\n// Lume 3\nsite.add("https://example.com/theme/styles.css", "styles.css");\nThe site.add() function also accepts npm specifiers:
site.add("npm:normalize.css", "/styles/normalize.css");\nInternally, this uses jsDelivr to download the file. In this example,\nnpm:normalize.css is transformed to\nhttps://cdn.jsdelivr.net/npm/normalize.css. Note that only one file is copied,\nnot all package files.
Note
\nsite.remoteFile is still required in Lume 3 for files not directly exported\nto the dest folder, like _data, _components or _includes files.
More info in the\ndocumentation page.
\nIn Lume 2, some plugins configure Lume to load files with a certain extension\nautomatically. For example, Postcss not only processes the CSS code but also\nconfigures Lume to load all CSS files:
\n// All .css files are loaded and processed\nsite.use(postcss());\nIn some cases, this is what you want. But if you don't want to load all CSS\nfiles, this behavior makes Lume load everything, and you have to use the\nsite.ignore() function or move the unwanted files to a folder starting with\n_.
In addition to that, this behavior is not fully transparent. You have to read\nthe documentation to know what the plugin is doing.
\nIn short, this approach causes more harm than good.
\nIn Lume 3, thanks to the site.add() function, it's very easy to add new files\n(and only the files that you want), so plugins no longer load files by\ndefault. You have to explicitly add them, which is more intuitive:
// Lume 2\nsite.use(postcss());\n\n// Lume 3\nsite.add([".css"]);\nsite.use(postcss());\nAnother benefit is you have better control of all entry points of your assets.\nFor example, for esbuild:
\n// Lume 3\nsite.add("main.ts");\nsite.use(esbuild()); // Only main.ts is bundled\nThis change affects the svgo, transform_images, picture, postcss,\nsass, tailwindcss, unocss, esbuild and terser plugins.
Lume started supporting JSX as a template engine thanks to the jsx plugin\nthat uses React under the hood. Later, the jsx_preact plugin was added to use\nPreact, a smaller and more performant alternative to React.
Having two JSX plugins for the same purpose is useless and adds unnecessary\ncomplexity (for example, combined with the MDX plugin).
\nMoreover, both libraries are frontend-first libraries, with features like hooks,\nevent callbacks, hydration, etc, that are not supported at build time, so some\npeople were confused about what they can or cannot do in Lume.
\nLume 3 has only one JSX plugin, and it doesn't use React or Preact but\nSSX, a TypeScript library created\nspecifically for static sites which is faster than React and Preact and more\nergonomic. It allows creating asynchronous components, inserting raw code like\n<!doctype html>, and comes with great documentation including all HTML\nelements and attributes, with links to MDN.
Lume 3 uses lume/jsx-runtime import source for all JSX and MDX files. So you\nonly have to configure the compilerOptions setting of deno.json as following\n(other options have been omited for brevity):
{\n "imports": {\n "lume/jsx-runtime": "https://deno.land/x/ssx@v0.1.8/jsx-runtime.ts"\n },\n "compilerOptions": {\n "jsx": "react-jsx",\n "jsxImportSource": "lume"\n }\n}\nThis allows to upgrade the library (or even replace it with something else)\neasily.
\nNote
\nWith the esbuild plugin you still can use React or Preact in Lume but for\nwhat they were created for: the frontend.
.page Subextension for JSX and TSX PagesLume requires the .page subextension for certain file types like .ts, .js,\nor .json to distinguish between files used to generate pages and those\nintended for browser execution. For instance, index.page.js generates the\nindex.html page, while index.js is a JavaScript file executed by the\nbrowser.
Starting with Lume 3, the .page subextension is also applied to .jsx and\n.tsx files. This change allows the .jsx and .tsx extensions to be\nexclusively used for browser-side code (after processing with the esbuild\nplugin).
Lume 2:\n- /index.jsx\n\nLume 3:\n- /index.page.jsx\nIf you prefer the Lume 2 behavior (where this differentiation is not required),\nyou can configure the plugin to remove the .page subextension:
site.use(jsx({\n pageSubExtension: "", // Reverts to Lume 2 behavior\n}));\nMore info in the plugin documentation.
\nOne of the main limitations of Lume 2's components was that they were\nsynchronous. This was to support JSX components that were synchronous with React\nand Preact. With SSX, we don't have this limitation anymore, and all components\nare async.
\nFor example, you can create a component in JSX that returns a promise:
\n// _components/salute.jsx\n\nexport default async function ({ id }) {\n const response = await fetch(`https://example.com/api?id=${id}`);\n const data = await response.json();\n return <strong>Hello {data.name}</strong>;\n}\nThis component can be used in any other template engine, like JSX:
\nexport default async function ({ comp }) {\n return (\n <p>\n <comp.Salute id="23" />\n </p>\n );\n}\nOr Vento:
\n<p>{{ comp.Salute({ id: 23}) }}</p>\nLume components not only generate HTML code but can also export the CSS and JS\ncode needed to run it on the browser. The code must be exported in the variables\ncss and js. For example:
---\ncss: |\n .mainTitle {\n color: red;\n }\n---\n\n<h1 class="mainTitle">{{ name }}</h1>\nThe problem with this approach is the CSS and JS code is not treated as CSS and\nJS code by your code editor, so there's no syntax highlighting.
\nIn Lume 3, it's possible to create a component in a folder, with the CSS and JS\ncode in different files. To do that, you use the following structure:
\n|_ _components/\n |_ button/\n |_ comp.vto\n |_ style.css\n |_ script.js\nAny folder containing a comp.* file will be loaded as a component using the\nfolder name as the component name, and the style.css and script.js files\nwill be loaded as the CSS and JS code for the component. This makes the creation\nof components more ergonomic, especially for cases with a lot of CSS and JS\ncode.
Additionally, it's possible to add a script.ts file instead script.js to use\nTypeScript. Lume will compile it to JavaScript automatically.
In Lume 2 components created with text-based engines, like Vento didn't work\nwell for JSX templates. For example, let's say we have the following Vento\ncomponent:
\n<button>{{ content }}</button>\nand we want to use it in a JSX page:
\nexport default function ({ comp }) {\n return <comp.Button>Click here</comp.Button>;\n}\nDue JSX escapes the string values, the output code is this:
\n<button>Click here</button>\nTo fix it, we need to create a container element with the\ndangerouslySetInnerHTML attribute:
export default function ({ comp }) {\n return (\n <div\n dangerouslySetInnerHTML={{\n __html: <comp.Button>Click here</comp.Button>,\n }}\n />\n );\n}\nIn Lume 3, thanks to SSX this is no longer necessary. Components are fully\ninteroperable and you can insert JSX components in Vento and viceversa. And to\nmake them even more interchangeable, the content and children variables are\nequivalent.
export default function ({ comp }) {\n return (\n <>\n // This works\n <comp.Button>Click here</comp.Button>\n\n // This also works\n <comp.Button content="Click here" />\n </>\n );\n}\nIn Lume 3, components can have extra data that will be used as default values.\nThis data is like layout data but applied to components.
\nLet's see the following _components/title.vto component as an example :
---\ntitle: Hello world\n---\n\n<h1>{{ title }}</h1>\nNow you can use the component with the default title.
\n{{ await comp.title() }}\n<!-- <h1>Hello world</h1> -->\nOr with a custom title
\n{{ await comp.title({ title: "New title" }) }}\n<!-- <h1>New title</h1> -->\nAs mentioned, Lume components can output CSS and JS code. However, some plugins\noutput code too. For example, google_fonts generates the CSS code needed to\nload the fonts, prism and code_highlight export the CSS code with the\nthemes, and katex (that didn't generate CSS code in Lume 2) now generates the\nCSS code automatically so you don't need to copy manually the CSS code.
Additionally, some plugins download also font files (specifically,\ngoogle_fonts and katex).
In Lume 2, you have to configure how to export the generated code for every\nplugin individually. In Lume 3 there are three global options that will be used\nby default by all plugins and components:
\nconst site = lume({\n cssFile: "/style.css", // default value\n jsFile: "/script.js", // default value\n fontsFolder: "/fonts", // default value\n});\nAll extra code generated by components and the plugins code_highlight,\ngoogle_fonts, prism, katex and unocss will be stored there.
Of course, you can still change the code destination for a specific plugin:
\nsite.use(unocss({\n cssFile: "/unocss-styles.css",\n}));\nThe tailwindcss plugin was upgraded to use\nTailwind 4. The new version is\nfaster than v3 and no longer needs Postcss to work. There are many changes in\nthe configuration (especially the CSS-first configuration) so take a look at the\nupgrade guide if you want to\nupgrade your projects from v3 to v4.
// Lume 2\nsite.use(tailwindcss());\nsite.use(postcss());\n\n// Lume 3\nsite.use(tailwindcss());\nsite.add("style.css");\nIf you don't want to upgrade to v4, it's still possible to continue using\nTailwind 3 with the postcss plugin:
\nimport tailwind from "npm:tailwindcss@^3.4";\n\nsite.use(\n postcss({\n plugins: [tailwind()],\n }),\n);\nMore info in the plugin documentation.
\nsite.process() and site.preprocess() are among Lume's most used features.\nLume 3 brings some improvements here to make them easier to use.
page.document no longer returns undefinedOne of the many uses of processors is to manipulate HTML pages using the\npage.document property. But this property can return undefined if the page\nis not HTML or cannot be parsed, so you have to check the variable type before\nusing it:
site.process([".html"], (pages) => {\n for (const page of pages) {\n const document = page.document;\n if (!document) {\n continue;\n }\n const title = document.querySelector("title");\n }\n});\nIn Lume 3, page.document always returns a Document instance or throws an\nexception if the page cannot be parsed. This allows us to omit the type check:
site.process([".html"], (pages) => {\n for (const page of pages) {\n const title = page.document.querySelector("title");\n }\n});\nThe page.content variable containing the content of the page can be a string\nor a Uint8Array, depending on how this page has been loaded. For example,\nHTML, CSS or JS pages have the content as a string, but images or other binary\nfiles are loaded as Uint8Array.
To process these files in Lume 2 you have to check the content type:
\nsite.process([".css"], (pages) => {\n for (const page of pages) {\n const content = page.content;\n\n if (typeof content === "string") {\n page.content = "/* Ā© 2025 */" + content;\n }\n }\n});\nIn Lume 3, pages have two new properties: page.text and page.bytes (inspired\nby the same properties of the\nRequest\nobject). As you may guess, page.text allows to work with the page content as\nstrings, making the conversions automatic, and page.bytes does the same but\nfor Uint8Array.
site.process([".css"], (pages) => {\n for (const page of pages) {\n page.text = "/* Ā© 2025 */" + page.text;\n }\n});\n* wildcardIn Lume 2, the * wildcard allows you to process all pages:
site.process("*", (pages) => {\n // Process all pages\n});\nIn Lume 3, the first argument can be omitted:
\nsite.process((pages) => {\n // Process all pages\n});\nIn Lume 2, the order in which some plugins are registered doesn't matter. Let's\nsee this example from the sitemap plugin:
site.use(sitemap()); // Generate the sitemap file\nsite.use(basePath()); // Add the base path to all URLs\nThe sitemap plugin is registered before basePath, so you may think the sitemap\nfile is generated before adding the base path prefix to all URLs. But\ninternally, the sitemap plugin is executed using the "beforeSave" event, which\nis triggered at the end, just before saving all files to the _site folder. So\ninternally the basePath plugin is executed before.
\nThis was designed so you don't have to think about the order of the plugins when\nusing them. But this behavior has two problems:
\nTo make Lume more transparent and intuitive, many plugins using events were\nchanged to use processors, which respect the order in which they are registered\nin the _config.ts file.
\nThe affected plugins are: code_highlight, decap_cms, favicon, feed,\ngoogle_fonts, icons, prism, robots, sitemap, and slugify_urls.
To help with this transition, Lume 3 comes with a\nlint plugin that warns\nyou when the order of some plugins is not correct.
\n![\"Image\"](\"https://lume.land/uploads/lint.png\")
esbuild-deno-loader to resolve dependenciesDeno is becoming a complicated runtime, especially for everything related to\nmodule resolution. It supports three completely different types of packages\n(HTTP, NPM, and JSR), with different behaviors, inconsistencies, and\nincompatibilities between them. In addition to the usual complexity of NPM, in\nDeno a package can be located in different places, depending on the variable\nnodeModulesDir, if the file package.json is found, if the node_modules\nfolder exists, etc. JSR is not much better, because the resolution of a package\ndepends on the combination of imports, exports, and patch keys in\ndifferent deno.json and deno.jsonc files. And the addition of workspaces\nadds a new layer of complexity.
In Lume 2, the esbuild plugin delegates all this complexity to\nesm.sh, which transforms any NPM or JSR package to simple\nHTTP imports that are easier to manage. But this solution has its problems with\nmultiple configuration options (deps, pin, alias, standalone, exports,\netc) and there are many packages that don't work well after passing them through\nesm.sh.
In Lume 3 the esbuild plugin uses the\nesbuild-deno-loader plugin created\nby Luca Casonato, a member of the Deno team. This will make your bundled code\nmore reliable and compatible with how Deno works.
basename improvementsIn Lume 2, the basename variable allows changing the name of a file or\ndirectory. When missing, it's automatically defined by Lume using the page\nfilename. For example, the page /posts/first-post.md has the basename\nfirst-post.
In Lume 3 this variable uses the final URL of the page, instead of the source\nfilename. For example, if the /post/first-post.md page generates a different\nURL (say /post/other-name/) the basename is other-name.
Additionally, the basename no longer accepts "index" as a value. For example,\nthe basename for the /post/hello-world/index.md is hello-world (the folder\nname) instead of index (the filename).
These changes will make this variable more consistent across all pages, no\nmatter how the URL is generated. It's especially important for the nav plugin\nthat uses this variable to sort pages alphabetically.
Lume 2 detects automatically the date value from the files and folders paths\nand remove it. For example, the file /posts/2020-06-21_hello-world.md outputs\nthe page /posts/hello-world/ (without the date).
Some people don't want this behavior and prefer to keep the date in the output\nURL. Following the Lume's philosophy of having a light core and provide extra\nfeatures through plugins, this feature was removed from the core and the new\nextract_date plugin was created to enable it.
import lume from "lume/mod.ts";\nimport extractDate from "lume/plugins/extract_date.ts";\n\nconst site = lume();\n\nsite.use(extractDate());\n\nexport default site;\nBy default the plugin provides the same behavior of Lume 2, but it's possible to\nextract the date without removing it from the URL:
\nimport lume from "lume/mod.ts";\nimport extractDate from "lume/plugins/extract_date.ts";\n\nconst site = lume();\n\nsite.use(extractDate({\n remove: false, // Keep the date\n}));\n\nexport default site;\nIn addition to jsx_preact, two more plugins were removed in Lume 3: liquid\nand on_demand.
Liquid lets you using LiquidJS as a template engine to\nbuild pages. The syntax is very similar to Nunjucks and the library is actively\nmaintained but it has a big limitation: it's not possible to invoke functions.\nThis makes this template engine useless in Lume because it's not possible to use\nhelpers like search or nav to search pages or build the navigation. The\nplugin has been deprecated for a while, and it was removed in Lume 3.
The on_demand plugin was mainly an experiment to see if it was possible to add\nsome dynamic behavior to Lume sites. But it never worked well, the\nimplementation was a bit hacky to make it work on Deno Deploy, and it was too\nlimited. Lume has the router for simple use\ncases, and for complex cases, maybe you have to use a different framework. The\npurpose of Lume never was to become into one-size-fits-all solution.
The following removals aim to improve the stability and interoperability between\nplugins.
\nextensions optionIn Lume 2, some plugins have the extensions option to configure which files\nyou want to process. You rarely need to modify this option because Lume provides\nsensible defaults. For example, the default value for\nPostcss plugin is [".css"]:
site.use(postcss({\n extensions: [".css"], // <- You don't need this\n}));\nIn most cases, this option doesn't make sense, because you can set any value but\nthe plugin expects a specific format, like HTML pages to use DOM API or CSS code\nto process:
\nsite.use(postcss({\n extensions: [".html"], // <- This breaks the build\n}));\nIn Lume 3, this option was removed in many plugins:
\n.css files..scss and .sass files..svg files..css and\n.html files..html pages.There are other plugins that register filters or helpers that you can use in\nyour pages. In Lume 2 you could customize the name of these elements. For\nexample, it's possible to use a different key to store the data for the metas\nplugin:
site.use(metas({\n name: "opengraph",\n}));\nOr the filter name of the date plugin:
site.use(date({\n name: "get_date",\n}));\nChanging the default name of the plugins have two problems:
\nmetas to opengraph, Lume.Data.metas still exist.picture and\ntransform_images depend on the same key name. If you change it for only one\nplugin, the other won't work.In Lume 3, the name option was removed in the following plugins, so it's no\nlonger possible to change it to something else: date, json_ld, metas,\nnav, paginate, picture, reading_info, search, transform_images,\nurl and postcss.
transform_images, favicon and og_imagesattribute option in inline.comp variable. The option to customize this\nvariable name has been removed.Most Lume users don't change these options, so most likely these removals don't\naffect your upgrade to Lume 3.
\nThe Temporal proposal provides\nstandard objects and functions for working with dates and times. It's being\nimplemented in all browsers and it's supported by Deno with the\nunstable-temporal flag. Lume 2 uses\na polyfill, but Lume 3\nuses the Deno implementation, which requires to enable it in deno.json file:
{\n "unstable": ["temporal"]\n}\nAs of version 3, Lume will support at least the most recent Deno LTS version\n(and probably some older versions too). Lume 3.0 supports Deno 2.1 and greater.\nMore info\nabout Deno LTS releases.
\nLume 2 automatically added <!doctype html> to any HTML pages that were missing\nit. The original reason was because JSX doesn't allow adding this directive, so\nit was difficult to create HTML pages with only JSX. However, some users don't\nwant this behavior because they create files with fragments of HTML. In Lume 3,\nit is possible to add the doctype directive in JSX (thanks to SSX) so this\nbehavior is no longer needed and was removed.
As always, you can see\nthe CHANGELOG.md file\nfor a complete list of all changes with more details.
\nWhile the development server is running, Lume 3 features a debug bar that\nprovides valuable insights, including warnings and issues flagged by plugins.
\n![\"Image\"](\"https://lume.land/uploads/debugbar.png\")
The Lume debug bar can be extended easily by plugins or directly in the\n_config.ts. For example, let's create a simple tab to list all pages without\ntitle:
function createTab() {\n // Create a collection in the debug bar\n const collection = site.debugBar?.collection("Pages without title");\n\n // The debug bar is enabled if the collection was created\n if (collection) {\n collection.icon = "file";\n\n // Add items to the collection\n collection.items = site.pages\n .filter((page) => page.outputPath.endsWith(".html")) // Only HTML pages\n .filter((page) => !page.data.title) // No title\n .map((page) => ({\n title: page.data.url,\n actions: [\n {\n text: "Visit",\n href: page.data.url,\n },\n ],\n }));\n }\n}\n\n// Run this function after building and updating the site\nsite.addEventListener("afterBuild", createTab);\nsite.addEventListener("afterUpdate", createTab);\nThat's it! Our custom tab is now part of the Lume debug bar, and it has already\nidentified two pages without titles!
\n![\"Image\"](\"https://lume.land/uploads/custom-debug-tab.png\")
The Lume debug bar is still an experimental feature, but it has been very well\nreceived since its introduction in our Discord community. Developers are already\nworking on plugins to enhance the debug bar with features like HTML validator\nreports, accessibility checks, and SEO analysis.
\nKeep in mind that the debug bar is only visible when running Lume with\ndeno task serve. It is not included in production builds. If you wish to\ndisable this feature completely, you can do so by editing the _config.ts file:
const site = lume({\n server: {\n debugBar: false, // disable the debug bar\n },\n});\nAll this work wouldn't be possible without the help from all people that\ncontribute to Lume. Thanks to everyone that\nsponsor Lume\nor directly me. Thanks also to people\nthat have been testing Lume 3 in the latest months or even using it in real\nprojects, reporting bugs and providing feedback (specially\nTim Post and Rick Cogley),\nand thanks to Pyrox for reviewing the grammar of this\npost.
\n","date_published":"Wed, 07 May 2025 00:00:00 GMT"},{"id":"https://lume.land/blog/posts/lume-2-5-0-pedro-munho/","url":"https://lume.land/blog/posts/lume-2-5-0-pedro-munho/","title":"Lume 2.5.0 - Pedro DĆas and MuƱo Vandilaz","content_html":"Feliz aninovo š!
\nNew year and new Lume version! This time, I'd like to dedicate it to Pedro DĆas\nand MuƱo Vandilaz, who married on April 16, 1061, almost a thousand years ago.\nThis is the first same-sex marriage documented in Galicia (and the rest of\nSpain).
\nThe wedding took place in a small Catholic chapel. It's surprising to see how\nhomophobic prejudices have changed since then. If you want to read more about\nthis event take a look at\nthis Qnews article (English)\nor\ngCiencia post (Galician).
\n\njson_ldJSON-LD (JSON for Linking Data) is a way to provide\nstructured data to web pages using JSON format, which\nis easier to parse and doesn't require to modify the HTML code. It's defined\nwith a <script type="application/ld+json"> element containing the JSON code.\nFor example:
<script type="application/ld+json">\n {\n "@context": "https://schema.org",\n "@type": "WebSite",\n "url": "https://oscarotero.com/",\n "headline": "Ćscar Otero - Web designer and developer",\n "name": "Ćscar Otero",\n "description": "Iām just a designer and web developer",\n "author": {\n "@type": "Person",\n "name": "Ćscar Otero"\n }\n }\n</script>\nThe json_ld plugin, created by Shuaixr, makes\neasier to work with this structured data. Edit your _config file to install\nit:
import lume from "lume/mod.ts";\nimport jsonLd from "lume/plugins/json_ld.ts";\n\nconst site = lume();\nsite.use(jsonLd());\n\nexport default site;\nThen, you can create the jsonLd variable in your pages. For example:
jsonLd:\n "@type": WebSite\n url: /\n headline: Ćscar Otero - Web designer and developer\n name: Ćscar Otero\n description: Iām just a designer and web developer\n author:\n "@type": Person\n name: Ćscar Otero\nNote the following:
\n@context property if it's missinglocation of the site.Like with other similar plugins like metas,\nyou can use field aliases:
\ntitle: Ćscar Otero - Web designer and developer\nheader:\n title: Ćscar Otero\n description: Iām just a designer and web developer\n\njsonLd:\n "@type": WebSite\n url: /\n headline: =title\n name: =header.title\n description: =header.description\n author:\n "@type": Person\n name: =header.title\nIf you want to use TypeScript, there's the Lume.Data["jsonLd"] type (powered\nby schema-dts package):
export const jsonLd: Lume.Data["jsonLd"] = {\n "@type": "WebSite",\n url: "/",\n headline: "Ćscar Otero - Web designer and developer",\n description: "Iām just a designer and web developer",\n name: "Ćscar Otero",\n author: {\n "@type": "Person",\n name: "Ćscar Otero",\n },\n};\nMore info in the\nplugin documentation page.
\npurgecssPurgeCSS is a utility to remove unused CSS code, making\nyour CSS files smaller to improve the site performance. The tool provides a\nPostcss plugin so, in theory, it can also be used in Lume. Now it has its own\nplugin (big thanks to into-the-v0id) which\nhas some advantages:
\nimport lume from "lume/mod.ts";\nimport purgecss from "lume/plugins/purgecss.ts";\n\nconst site = lume();\nsite.use(purgecss());\n\nexport default site;\nGo to the plugin documentation page for\nmore info.
\nrouter middlewareLume is a static site generator (and always will be). But sometimes you need\nsome server-side logic to handle small things. For example, to handle the data a\nuser sends from an HTML form, or maybe you need a small API to provide dynamic\ndata.
\nFor sites requiring front and back, you have great options like\nFresh, Astro or\nHono. But if you only need a couple of entry points, you\nmay consider using something simpler like router middleware, which is a\nminimal router that works great with Lume's server.
import Server from "lume/core/server.ts";\nimport Router from "lume/middlewares/router.ts";\n\n// Create the router\nconst router = new Router();\n\nrouter.get("/hello/:name", ({ name }) => {\n return new Response(`Hello ${name}`);\n});\n\n// Create the server:\nconst server = new Server();\n\nserver.use(router.middleware());\n\nserver.start();\nThat's all. Now the /hello/laura request will return a Hello laura response!
The router uses the standard\nURLPattern under\nthe hood that creates an object with all variables captured in the path and\npasses it as the first argument of the route handler.
\nIn addition to the captured variables, you have the request property with the\nRequest instance:
router.get("/search", ({ request }) => {\n const { searchParams } = new URL(request.url);\n\n const query = searchParams.get("query");\n return new Response(`Searching by ${query}`);\n});\nNote that to use this middleware in production, you need a hosting service\nrunning Deno like Deno Deploy or similar.
\nplaintext pluginSometimes you have your content in Markdown or HTML, but also need a plain text\nversion. Let's see the following example:
\n---\ntitle: Welcome to **my site**\n---\n<!DOCTYPE html>\n<html>\n <head>\n <title>{{ title }}</title>\n </head>\n\n <body>\n <h1>{{ title |> md(true) }}</h1>\n </body>\n</html>\nThe title variable uses Markdown syntax to render\nWelcome to <strong>my site</strong>. But this also affects the <title>\nelement of the page which contains the asterisks.
The new plaintext plugin registers the plaintext filter, that not only\nremoves any Markdown and HTML syntax but also linebreaks and extra spaces:
---\ntitle: Welcome to **my site**\n---\n<!DOCTYPE html>\n<html>\n <head>\n <title>{{ title |> plaintext }}</title>\n </head>\n\n <body>\n <h1>{{ title |> md(true) }}</h1>\n </body>\n</html>\nThe plugin is disabled by default so you need to import it to your _config.ts\nfile:
\nimport lume from "lume/mod.ts";\nimport plaintext from "lume/plugins/plaintext.ts";\n\nconst site = lume();\nsite.use(plaintext());\n\nexport default site;\nMore info in the\nplugin documentation page.
\nSome plugins like google_fonts,\nprism or\ncode_highlight can generate CSS\ncode. The way this code is generated is different for each plugin.
Google Fonts plugin has the cssFile option to configure the filename to output\nthe CSS code. If the css file doesn't exist, it's created. If it already exists,\nthe code is appended at the end. You can use the placeholder option to insert\nthe code at some point in the middle of the file.
site.use(googleFonts({\n cssFile: "styles.css",\n placeholder: "/* insert-google-fonts-here */",\n // ...more options\n}));\nPrism and Code Highlight plugins output the theme's CSS code differently. The\ntheme option has the path property but it's not the output css file but\nthe source file:
site.use(prism({\n theme: {\n name: "funky",\n path: "/_includes/css/code_theme.css",\n },\n}));\nThis means that if you set the path as /_includes/css/code_theme.css, this\nfile must be imported somewhere in your CSS code in order to be visible:
@import "css/code_theme.css";\nThe problem with this approach is it requires two steps: first, configure the\nsource file name in the plugin, and then import the file in your CSS file (or\ncopy it with site.copy()).
The Google fonts approach is more straightforward.
\nIn order to make Lume more consistent across all plugins, I want to unify the\nway the CSS code is generated everywhere. That's why the theme.path option of\nPrism and Code Highlight plugins are now deprecated and the new theme.cssFile\nand theme.placeholder options were added.
site.use(prism({\n theme: {\n name: "funky",\n cssFile: "styles.css",\n placeholder: "/* prism-theme-here */",\n },\n}));\nThis change is also aligned with the\ncomponents.placeholder option\nintroduced in Lume 2.4.
subset options to\nGoogle fonts plugin.ui.globalVariable option to\nPagefind plugin to store the pagefind\ninstance in a global variable for future manipulation..d.ts are ignored by Lume, to avoid generating empty\nfiles.See\nthe CHANGELOG.md file\nto see a list of all changes with more detail.
\n","date_published":"Sat, 11 Jan 2025 00:00:00 GMT"},{"id":"https://lume.land/blog/posts/lume-2-4-0-maruja-mallo/","url":"https://lume.land/blog/posts/lume-2-4-0-maruja-mallo/","title":"Lume 2.4.0 - Maruja Mallo","content_html":"Ola š!
\nThis new version of Lume is dedicated to\nMaruja Mallo, an extraordinary\nsurrealist painter born in Galicia in 1902 who gained international fame.\nLearn more about Maruja.
\n\ncheck_urlsBroken links are one of the biggest issues on the Web. A recent study detected\nthat\n27.6% of the top 10 million sites are dead.\nAnd for those sites that are still alive, they are likely to change the URLs at\nsome point, after a redesign or content updates, causing a lot of broken links.
\nThe new plugin check_urls will help you to keep your links healthy, by\nchecking all links in your website (not only to HTML pages but also files like\nimages, JavaScript or CSS). This plugin already existed for some time as\nexperimental plugin thanks\nto iacore, but it was moved to the main Lume repo\nand was improved with additional features.
The basic way to use it is like any other plugin. No big surprises here!
\nimport lume from "lume/mod.ts";\nimport checkUrls from "lume/plugins/check_urls.ts";\n\nconst site = lume();\nsite.use(checkUrls());\n\nexport default site;\nThe default configuration will check all your internal links and warns you when\na broken link is found. This plugin is compatible with\nredirects: when a link to a non-existing\npage is found, but it redirects to an existing page, the url is valid.
\nThere's a mode for a more strict detection:
\nsite.use(checkUrls({\n strict: true,\n}));\nIn the strict mode the redirects are not allowed, all links must go to the\nfinal page. This also affects to the trailing slashes: for example /about-me\nis invalid but /about-me/ is valid.
By default, the plugin only checks internal links. But you can configure it to\ncheck links to external domains:
\nsite.use(checkUrls({\n external: true,\n}));\nWarning
\nThis option can make the build slower, specially if you have many external\nlinks, so probably it's a good idea to enable it only occasionally.
\nLearn more about this plugin\nin the documentation page.
\niconsNowadays, most websites are using icons to a greater or lesser extent. The\nicons plugin allows to use some of the most popular SVG icon libraries. The\ninstallation can't be easier:
import lume from "lume/mod.ts";\nimport icons from "lume/plugins/icons.ts";\n\nconst site = lume();\nsite.use(icons());\n\nexport default site;\nTo import an icon, just use the icon filter which returns the path of the\nicon's svg file.
<img src="{{ "acorn" |> icon("phosphor") }}">\nLume will download the "acorn" icon from the popular\nPhosphor library into /icons/phosphor/acorn.svg\n(the output folder is configurable) and return the path.
Some icons have different variations that you can configure with the\nname:variation syntax:
<img src="{{ "acorn:duotone" |> icon("phosphor") }}">\nAlternatively, you can set the variation in the second argument of the filter:
\n<img src="{{ "acorn" |> icon("phosphor", "duotone") }}">\nYou can use inline plugin to inline the\nSVG code in the HTML.
<img src="{{ "acorn" |> icon("phosphor") }}" inline>\nThe icon plugin supports the following icon collections and it's easily\nextensible with more.
\nLearn more about this plugin\nin the documentation page.
\ngoogle_fontsAnother common asset used to build sites is webfonts.\nGoogle Fonts is a fantastic resource for open\nsource fonts, but loading the fonts from the Google Fonts CDN is not the best\noption, not only for privacy and GDPR compliance, but also\nfor performance.
\nThe google_fonts plugin downloads the optimized font files from Google fonts\nautomatically into the /fonts directory (configurable) and generates the\n/fonts.css file (also configurable) with the @font-face declarations.
To use it, just register the plugin passing the sharing URL of your font\nselection. For example, let's say we want to use\nPlayfair Display:
\nimport lume from "lume/mod.ts";\nimport googleFonts from "lume/plugins/google_fonts.ts";\n\nconst site = lume();\n\nsite.use(googleFonts({\n fonts:\n "https://fonts.google.com/share?selection.family=Playfair+Display:ital,wght@0,400..900;1,400..900",\n}));\n\nexport default site;\nIt's possible to rename the fonts, useful if you want to change a font without\nchanging the code:
\nsite.use(googleFonts({\n fonts: {\n display: "https://fonts.google.com/share?selection.family=Playfair+Display:ital,wght@0,400..900;1,400..900",\n text: "https://fonts.google.com/share?selection.family=Roboto:ital,wght@0,100;0,300;0,400;0,500;0,700;0,900;1,100;1,300;1,400;1,500;1,700;1,900"\n}));\nIn the example above, the Playfair Display font is renamed to "display" and\nRoboto to "text", so this allows the use of the fonts in the CSS code with\nthese names:
\nh1 {\n font-family: display;\n}\nbody {\n font-family: text;\n}\nGo to the documentation page to learn\nmore about the Google Fonts plugin!
\nbrotli and gzipThanks to Into the V0id for adding these two\nplugins to Lume. They are useful for compressing text-based files (like HTML,\nJavaScript, SVG, or CSS files) using the Gzip and Brotli algorithms and output\nfiles with the same name but with .gz or .br extensions. For example, in\naddition to the /index.html page, the plugins generate also /index.html.gz\n(for Gzip) and /index.html.br (for Brotli).
I think it's not necessary to show how to activate the plugin, but just to\ndemonstrate how predictable and "boring" Lume is:
\nimport lume from "lume/mod.ts";\nimport brotli from "lume/plugins/brotli.ts";\n\nconst site = lume();\n\nsite.use(brotli());\n\nexport default site;\nprecompress middlewarebrotli and gzip plugins can be combined with\nthe new precompress middleware\nif you're using Lume server to serve your\nstatic files (for example in Deno Deploy). This middleware checks the\nAccept-Encoding header and if the browser accepts br or gzip values, it\nwill serve the precompressed file.
import Server from "lume/core/server.ts";\nimport precompress from "lume/middlewares/precompress.ts";\n\nconst server = new Server();\n\nserver.use(precompress());\n\nserver.start();\nLearn more about these plugins in the\nbrotli and\ngzip documentation pages.
\nmodify_urls supports CSS filesThe modify_urls plugin now can\nsearch and modify urls in CSS files. This is not important only for this plugin\nbut also for other plugins that use modify_urls under the hood, like\nbase_path and\nrelative_urls.
base_pathbase_path is one of Lume's most useful plugins because it adds a prefix to all\nabsolute URLs of your site. This is important if your site is hosted in a\nsubdirectory.
For example, let's say you want to host your blog in the location\nhttps://my-site.com/blog/ and you have this HTML code:
<a href="/posts/hello-world/">Hello world</a>\nThe plugin automatically fixes the URL to add the /blog/ prefix:
<a href="/blog/posts/hello-world/">Hello world</a>\nUntil now, the plugin only transformed URLs in HTML pages. If your site has this\nCSS code:
\n.background {\n background-image: url("/img/bg.png");\n}\nThe background image will fail because the /blog/ prefix is missing. As of\nLume 2.4.0, this plugin can transform also CSS files. This option is disabled by\ndefault, it requires to configure it in the _config.ts file:
site.use(basePath({\n extensions: [".html", ".css"],\n}));\nNow not only HTML pages but also CSS files will be processed:
\n.background {\n background-image: url("/blog/img/bg.png");\n}\nImportant
\nKeep in mind that Lume only processes files that are loaded. To transform CSS\nfiles they must be loaded before. If you're using any styling plugin like\npostcss,\nlightningcss, or\nsass, you don't need to do anything else.\nBut if you are copying the css files with site.copy([".css"]) or\nsite.copy("/styles") they won't be processed. To fix it, you have to use\nsite.loadAssets([".css"]).
metas and feed pluginsSome plugins like metas and feed allow to\ndefine aliases to other\nvariables. For example, if we want to use the variable title inside\nmetas.title:
title: Page title\nmetas:\n title: =title\nAs of Lume 1.4, it's possible to define fallbacks to other variables or provide\na default variable:
\nmetas:\n title: =title || =header.title || Default title\nIn this example, the title used in metas is the title variable. If it's not\ndefined, the header.title variable is used. And if it's doesn't exist, the\nstring "Default title" will be used.
feed pluginIn addition to fallbacks, the feed plugin\nhas added support for the author name and author URL variables:
site.use(feed({\n output: ["/posts.rss", "/posts.json"],\n query: "type=post",\n info: {\n title: "=site.title",\n description: "=site.description",\n authorName: "=site.author.name",\n authorUrl: "=site.author.url",\n },\n items: {\n title: "=title",\n description: "=excerpt",\n authorName: "=author.name",\n authorUrl: "=author.url",\n },\n}));\nesbuild plugin\nby Into the V0id.fediverse to the\nmetas plugin, to generate the\n<meta name="fediverse:creator" content="..."> tag\nadded to Mastodon.placeholder in the\nunocss plugin to insert the generated\ncode in a specific place.placeholder in the\ncomponents configuration to insert\nthe generated CSS and JavaScript code in a specific place.And more changes. See the\nCHANGELOG file for\nmore details.
\nHappy Luming!
\n","date_published":"Wed, 06 Nov 2024 00:00:00 GMT"},{"id":"https://lume.land/blog/posts/lume-2-3-0-andres-do-barro/","url":"https://lume.land/blog/posts/lume-2-3-0-andres-do-barro/","title":"Lume 2.3.0 - AndrƩs do Barro","content_html":"Lume 2.3.0 is dedicated to\nAndrƩs do Barro, a\nGalician singer and songwriter who was one of the first artists who achieved\nsuccess singing in Galego out of Galicia. Among his songs, we can find\nPandeirada and\nO trƩn.
\n\nIf you are using the nav plugin, see this.
parseBasenameWhen Lume loads a page file, the basename (the filename after removing the\nextension) is parsed to extract additional data. This feature makes it possible\nthat, for instance, if the basename starts with yyyy-mm-dd_*, Lume extracts\nthis value\nto set the page date,\nand remove it from the final name, so the file /2020-06-21_hello-world.md\ngenerates the page /hello-world/.
As of Lume 2.3.0, you can add additional parsers with the new function\nsite.parseBasename.
Let's say we want to use a variable named order to sort pages in a menu, and\nwe want to extract this value from the file name. For example the file\n/12.hello-world.md outputs the page /hello-world/ and sets 12 as the\norder variable. We can achieve this with the following function:
site.parseBasename((basename) => {\n // Regexp to detect the order pattern\n const match = basename.match(/(\\d+)\\.(.+)/);\n\n if (match) {\n const [, order, basename] = match;\n\n // Return the order value and the new basename without the prefix\n return {\n order: parseInt(order),\n basename,\n };\n }\n});\nAs you can see, the function is simple: it receives the basename and return an\nobject with the parsed values. Note that the returned object contains the\nbasename without the prefix, in order to be removed from the final URL.
\nSee more info in the\ndocumentation page.
\n_config.ts and _cms.ts filesUntil now, if you modify the _config.ts file during the server mode, you must\nstop the process and start it again to see the changes. This is very\ninconvenient, especially in the early phases of development, when you may want\nto try different plugins or make changes to the Lume configuration.
From now on, the building process is run inside a Worker. This change allows us\nto stop the build and restart it again without stopping the main process (under\nthe hood, it is done by closing the Worker and creating a new one).
\nFor now, the rebuild is triggered every time a change in the _config file is\ndetected. In the next versions, we can add additional triggers.
In CMS mode (with deno task cms), the process is also restarted if the\n_cms.ts file is modified, which is useful when you are configuring the\ndocuments and collections.
asc-locale and desc-localeWhen searching pages using the\nsearch helper, you can sort them by any\nfield, for example, the title:
const pages = search.pages("type=post", "title=asc");\nUnder the hood, Lume sorts the pages with\narray sort\nusing basic comparison operators (> and <):
pages.sort((a, b) => a == 0 ? 0 : a.title > b.title ? 1 : -1);\nThis works fine in many cases, but not when you have strings with accents,\ndifferent cases, etc. In these cases\nlocaleCompare\nworks much better. In this version, we have introduced two new locale methods:\nasc-locale and desc-locale. So the previous example can be improved with:
const pages = search.pages("type=post", "title=asc-locale");\nSRISRI (Subresource Integrity) is a browser feature to protect your\nsite and your users from compromised code loaded from external CDN. It verifies\nthe code loaded by the browser is exactly the same code that you got during the\nbuild process, without unexpected manipulations. You can\nlearn more about SRI in the MDN article.
\nLume had\nan experimental SRI plugin\nthat has been moved to the main repo, so now it's part of the official plugins\ncollection:
\nimport lume from "lume/mod.ts";\nimport sri from "lume/plugins/sri.ts";\n\nconst site = lume();\nsite.use(sri());\n\nexport default site;\nThe plugin searches for <script> and <link rel="stylesheet"> elements in\nyour pages that load resources from other domains and add the integrity and\ncrossorigin attributes automatically. For example, if you have this code:
<script src="https://code.jquery.com/jquery-3.7.0.slim.min.js"></script>\nThe plugin outputs the following:
\n<script\n src="https://code.jquery.com/jquery-3.7.0.slim.min.js"\n integrity="sha256-tG5mcZUtJsZvyKAxYLVXrmjKBVLd6VpVccqz/r4ypFE="\n crossorigin="anonymous"\n></script>\nSee more info\nin the plugin documentation page.
\nnav plugin changesImportant
\nIn this version, the nav plugin got a small BREAKING CHANGE (sorry for\nthat).
\nThe nav plugin is useful for creating menus at\nmultiple levels.
\nThe nav.menu() function returns an object tree using the pages' URL. Every\nobject in the tree is a page or a directory and in previous Lume versions, it\ncould have the following properties:
item.slug The name of the page or folder.item.data If the element is a page, this is the data object of the page. If\nit's a folder, this value is undefined.item.children An array of sub-pages and sub-folders.These properties didn't fit well to order the elements, especially the\nsub-folder items. In the new structure, the \n(Edit: it was restored in Lume 2.3.1 due some bugs) and this value is stored\nin slug property has been removeddata.basename.
This change affects to how this tree is iterated in your template. For instance,\nif in Lume 2.2 we have the following code:
\nif (item.data) {\n // item.data exists, it's a page\n return `<a href="{{ item.data.url }}">{{ item.data.title }}</a>`;\n} else {\n // It's a folder\n return `<strong>{{ item.slug }}</strong>`;\n}\nWith the changes in Lume 2.3, the code must be changed to:
\nif (item.data.url) {\n // item.data.url exists, it's a page\n return `<a href="{{ item.data.url }}">{{ item.data.title }}</a>`;\n} else {\n // It's a folder\n return `<strong>{{ item.slug }}</strong>`;\n}\nNow both pages and folder items store the basename in the same place\n(data.basename), and it's easy to sort the elements alphabetically:
const menu = nav.menu("/", "", "basename=asc");\nAnd even use the new locale sorting methods:
\nconst menu = nav.menu("/", "", "basename=asc-locale");\nIn this version the functions nav.nextPage() and navPreviousPage() have been\nadded, to ease the navigation to the next and previous pages.
For example, let's say we have created the following tree structure with the\nfunction nav.menu():
docs\n |__ getting-started\n |__ installation\n |__ configuration\n |__ plugins\n |__ prettier\nThe new function nav.nextPage returns the next page relative to the provided\nURL. For example:
const nextPage = nav.nextPage("/docs/getting-started/installation/");\nconsole.log(nextPage.url); // /docs/getting-started/configuration/\nIf the page is the last sibling of the current section, it returns the first\npage of the next section:
\nconst nextPage = nav.nextPage("/docs/getting-started/configuration/");\nconsole.log(nextPage.url); // /docs/plugins/\nIf the current section has children, it returns the first child:
\nconst nextPage = nav.nextPage("/docs/plugins/");\nconsole.log(nextPage.url); // /docs/plugins/prettier/\nThe nav.previousPage() works similarly but in reverse order.
Plugins and middlewares can be imported using named imports, in addition to\nthe default exports:
\nimport basePath from "lume/plugins/base_path.ts";\n// it's the same as\nimport { basePath } from "lume/plugins/base_path.ts";\nSeveral bug fixes and improvements have made to the watcher and live reload.
\nAnd there are many more changes that you can see in the\nCHANGELOG file.
\n","date_published":"Fri, 30 Aug 2024 00:00:00 GMT"},{"id":"https://lume.land/blog/posts/lume-2-2-0-luisa-villalta/","url":"https://lume.land/blog/posts/lume-2-2-0-luisa-villalta/","title":"Lume 2.2.0 - LuĆsa Villalta","content_html":"From now on, every new minor version of Lume will be dedicated to a relevant\ngalician person. Today ā17 Mayā is the\nGalician Literature Day\nand this year it was honored to the great poet\nLuĆsa Villalta. This Lume\nversion is dedicated to her.
\n\nCases requiring some manual changes after updating to Lume 2.2:
\n_cache folder in your src directory,\nsee this./lume/cms.ts, see this.The Esbuild plugin got the following\nimprovements:
\nJSR support: Now you can use jsr: specifiers in your\ncode. They are handled using esm.sh (the same as npm: specifiers).
Fixed npm: resolution. In previous versions, importing a bare specifier\nmapped to npm: like the following would fail:
{\n "imports": {\n "bar": "npm:bar"\n }\n}\nimport foo from "bar";\nThis has been fixed and it works fine now.
\nUsing esbuild without bundler: Let's say you want to compile the following\ncode with the bundle option to false:
import foo from "./bar.ts";\nEsbuild converts bar.ts to bar.js, but\nit doesn't change the file extension in the import.\nThe Lume plugin tries to fix this.\nMore info.
LumeCMS is a simple CMS to manage the content of the\nsites. To configure it, you have to create the _cms.ts file and import the CMS\nfrom the lume/cms.ts specifier:
import lumeCMS from "lume/cms.ts";\n\nconst cms = lumeCMS();\n\n// Configuration here\n\nexport default cms;\nThe file lume/cms.ts, provided by Lume, exports everything you need from\nLumeCMS. But this has also the following issues:
The best way to import LumeCMS is using the import map. This is something that\nthe init script\nhas been doing for a while. For example:
{\n "imports": {\n "lume/": "https://deno.land/x/lume@v2.2.0/",\n "lume/cms/": "https://cdn.jsdelivr.net/gh/lumeland/cms@0.4.1/"\n }\n}\nimport lumeCMS from "lume/cms/mod.ts";\n\nconst cms = lumeCMS();\n\n// Configuration here\n\nexport default cms;\nThis allows you to import only the specific modules of Lume that you need and\nupdate LumeCMS at your own pace.
\nI know this is a BREAKING CHANGE and sorry for that š. But I believe the\ncurrent situation wasn't easy to maintain.
\nshutdownIf you have a site on Deno Deploy that you want to shut down for reasons, this\nnew middleware can be useful:
\n/503.html page with the\n503 status code.Retry-After header with the default value of 24 hours\n(customizable).import Server from "lume/core/server.ts";\nimport shutdown from "lume/middlewares/shutdown.ts";\n\nconst server = new Server();\nserver.use(shutdown());\n\nserver.start();\ntheme option for Prism and Highlight.jsThe plugins prism and code_highlight highlight the syntax of your code\nautomatically using the libraries Prism and\nHighlight.js respectively. These libraries provide\nsome nice premade themes that you can use but need to be loaded manually.
A new option theme was introduced to ease this step, so the themes are\ndownloaded automatically. The option works the same for both plugins, this is an\nexample with prism:
site.use(prism({\n theme: {\n name: "funky",\n path: "_includes/css/code_theme.css",\n },\n}));\nThe CSS file for the\nFunky theme\nis downloaded automatically (using\nremoteFile under the hood) with the\nlocal path _includes/css/code_theme.css so you can import it in your CSS file\nwith:
@import "css/code_theme.css";\nNote
\nIf you're not using any CSS plugin (like postcss or lightningcss), you have to\nconfigure Lume to copy or load the file. Example:
\nsite.use(prism({\n theme: {\n name: "funky",\n path: "/css/code_theme.css",\n },\n}));\n\n// Copy the file\nsite.copy("/css/code_theme.css");\nmeta tagsThe metas plugin allows to include custom\nmeta tags. Useful to insert metas like twitter:label1, twitter:data1, etc.
In addition to the regular values, the metas object accepts additional values\nthat are treated as custom meta tags. Example:
title: Lume is awesome\nauthor: Dark Vader\nmetas:\n title: =title\n "twitter:label1": Reading time\n "twitter:data1": 1 minute\n "twitter:label2": Written by\n "twitter:data1": =author\nThis configuration generates the following code:
\n<meta name="title" content="Lume is awesome" />\n<meta name="twitter:label1" content="Reading time" />\n<meta name="twitter:data1" content="1 minute" />\n<meta name="twitter:label2" content="Written by" />\n<meta name="twitter:data2" content="Dark Vader" />\nThe feed plugin has been extended with the\nnew image key that allows one to place an image per item. For example:
site.use(feed({\n output: "/feed.xml",\n query: "type=articles",\n items: {\n title: "=title",\n description: "=excerpt",\n image: "=cover",\n },\n}));\nLiquid plugin allows to use\nLiquidjs library as a template engine in Lume.
\nLiquidjs is a great library but it has a limitation incompatible with Lume:\nit's not possible to invoke functions.\nThis is very unfortunate because it's not possible to use the\nsearch helper inside a liquid\ntemplate to loop through the pages. For example, the following code doesn't\nwork:
<ul>\n {% for item in search.pages('post') %}\n <li>{{item.title}}</li>\n {% endfor %}\n</ul>\nLume has support for Nunjucks which is a good replacement because has a very\nsimilar syntax to Liquid and allows you to run functions, so I decided to\ndeprecate the Liquid plugin and recommend Nunjucks instead. It will still be\navailable in Lume 2 but probably be removed in Lume 3 (in the distant future).
\n_cache folder relative to root directoryThe _cache folder is created by some plugins like\ntransform_images in the source\nfolder. For example, if your source folder is ./src/ the cache folder is\n./src/_cache/.
As of Lume 2.2.0, this folder is created in the root directory (the same\ndirectory where the _config.ts file is). This makes its location more\npredictable, especially to add it to .gitignore.
After updating Lume, if you are using a subdirectory as the source folder, the\n_cache folder should be moved to the root.
The postcss plugin comes with the plugins\npostcss-nesting and\nautoprefixer enabled by default.
\nCSS nesting\nis now available in all browsers and this plugin is no longer needed, so it's no\nlonger enabled by default in Lume.
\nIf you still want to use it, you have to import it in the _config.ts file:
\nimport lume from "lume/mod.ts";\nimport postcss from "lume/plugins/postcss.ts";\nimport nesting from "npm:postcss-nesting";\n\nconst site = lume();\n\nsite.use(postcss({\n plugins: [nesting()],\n}));\n\nexport default site;\nAnd there are many more changes that you can see in the\nCHANGELOG file.
\n","date_published":"Fri, 17 May 2024 00:00:00 GMT"}]}