Hi,

Cool framework. I'm trying it out and found somethings that might improve the create experience.

This eslint packages are missing in the the eslint config that is added:

@typescript-eslint/eslint-plugin@latest 
eslint-plugin-react@latest
eslint-plugin-jsx-a11y@latest

And a nice to have will be to be able to run the create command with a dirty repo. Maybe one ones to migrate to radish and is a bit complicated if one needs to delete all.

Thanks again for the effort

Right now, Radish does a couple things that make the HTML authoring experience nicer:

• HTML files are automatically nested in folders for nicer routing. For example, if a page is src/about.jsx, Radish will place the built file at about/index.html so that the path in the browser is /about/.
• Radish generates an HTML "shell" — the doctype, html, head and body tags.

These are both convenient for normal pages, but unnecessary for RSS, which is accessed by visiting the file directly (/blog/feed.xml) and doesn't need any sort of "shell" around it.

A solution to the first might be allowing the paths function to return file names as well. If the last segment of a path has an extension, Radish would create a file with that name and extension, rather than creating a folder and placing an index.html inside it.

I'm not sure how to solve the second right now — maybe another export from pages (export const shell = false;) that instructs Radish not to generate the surrounding markup?

Service workers can pre-populate their cache on install (MDN docs. It would be nice if Radish generated a service worker that pre-cached entire pages and their assets, controlled by the user. One possible API would be something like radish build --offline "/foo" --offline "/bar", where /foo and /bar are paths generated. Radish could look at the esbuild metafile to see which assets corresponded to those pages and cache them all on install.

The obstacle to this is that the content on each page isn't known when bundling — Radish imports all of it and pages can filter it in JavaScript when rendering the component. This is fine for text that gets included in the HTML, but any assets such as images would be missing.

One possible solution is to overload the import in order to make the content known statically. For example, import posts from "content/blog/*"; could import all blog posts and associated assets, which would allow esbuild to associate them with the given entry point. There are a couple issues, though — it's less flexible than getting all content in a big JS object that you can do whatever you want with, and it feels a bit too far removed from normal ES module imports.

Radish supports assets references with url() for TOM, YAML and JSON content but does not support the use of url() in Markdown frontmater. It would be nice to support the use of assets within Markdown frontmatter.