a quick and dirty static site generator
|
|
5 maanden geleden | |
|---|---|---|
| src | 5 maanden geleden | |
| .gitignore | 11 maanden geleden | |
| .nvmrc | 11 maanden geleden | |
| README.md | 11 maanden geleden | |
| eslint.config.js | 11 maanden geleden | |
| package-lock.json | 5 maanden geleden | |
| package.json | 5 maanden geleden |
a quick and dirty static site generator.
Run this script from a directory containing markdown, templates and styles and a dist/ directory will be created
containing the rendered-out static assets ready for deployment.
While the defaults should work for most (of my) use cases, you can configure behaviour using a rhedyn.config.js in the
directory where you run the tool.
"Rhedyn" is Welsh for "fern", and is pronounced a bit like "read in".
The default config will look for .md files in the markdown/ directory, .scss files in the styles/ directory, and
handlebars (.hbs) files in the templates/ directory.
The styles will be compiled using sass and output to a matching path in the dist/ directory with a .css file
extension. These file paths are made available to the template renderer, for inclusion as whatever tags you see fit.
Markdown is compiled using marked with the marked-code-preview extension enabled, then passed to the template
renderer in the content property.
Once the markdown content and template have been rendered out, the resulting .html file is output to dist/, again
with the matching path (e.g. markdown/recipes/soup.md would be rendered to dist/recipes/soup.html).
Usual stuff applies - install as a module locally or globally and call the default function:
npx rhedyn
"scripts": {
"build": "rhedyn"
}
You can also build a self-contained executable if you like chunky binaries with npm run build. That'll output to the
dist/ directory, and you can then put that binary wherever you like (probably somewhere in your $path).
A working example of how to configure can be found in src/defaults.js, with the processors separated out to
src/processors.js for tidiness.
Your rhedyn.config.js should export an object with "tasks" and "opts". These are detailed below.
If you want to extend the default config, it can be imported as defaultConfig from this package.
The opts object in your config is for anything related to the project as a whole, rather than individual tasks. That
means things like the base output directory, where to find templates for the renderer, etc. It'll be passed to the
processor function as a key on the meta object.
opts can also have an include property, an object containing task keys (e.g. "styles") and paths to include for
that task, such as additional styles or templates. The path can be anywhere, not just local to the project - I use it to
include basic typography styles that I know I'll want in every project, but it could just as easily be used to produce a
sort-of "theme" that could be shared across multiple projects.
opts: {
baseDir: 'dist/',
templatesDirs: ['templates/'],
defaultTemplate: 'default',
include: { styles: ['~/.rhedyn/styles/'] }
},
Tasks should be an array of objects that look something like this:
{
name: "styles",
inputDirs: ["styles/"],
outputDir: "static/styles/",
inputFileExtension: ".scss",
outputFileExtension: ".css",
processor: compileSass
}
All properties are mandatory, and simply specify where we're reading the files in from and their extensions then where
to put them once we've processed them. inputDirs is an array of paths, so you could include multiple paths here if you
wish (some SCSS from a node module, for example).
processor is a function that takes a file path as it's first argument, which is
the file path to process, and meta as the second argument. meta contains the opts object, along with the
already-processed filepaths from other tasks:
{
opts: {
baseDir: 'dist/',
templateDirs: ['templates/'],
defaultTemplate: 'default',
include: { styles: ['~/.rhedyn/styles/'] }
},
resources: { styles: [
{ path: 'static/styles/main.css', detail: {} }
] }
}
A processor is just a function that takes a filepath and meta, returns an object with the processed result and
optionally detail. detail can contain any properties you like, and is generally for annotating things like "date" or
"author" that might be extracted from the source file (think frontmatter and the like).
Some examples can be found in src/processors.js, and you can find some utility functions exported from this package as
utils. The sample processors are also exported from this module, as processors.