npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

crust-io

v2.1.0

Published

Static site generator with support for hiearichal page structure.

Downloads

10

Readme

Crust

Static site generator with support for hierarchical page structure.


Static site source


Generator


To get started you need to have an app-folder with the page templates and content data. The best way to get a project structure set up, is to use the Yeoman generator, which can be found here: generator-crust

Follow the instructions in the readme, and you should be up and running in no time.


General crust file structure


Crust basically works by merging content into templates, eventually turning the finished product into static HTML.

The source elements needs to reside inside the app-folder. The default way the folders inside app are structured is as follows:

├── app/
│   ├── source
│   ├── templates
│   │   ├── components
│   │   ├── master
│   │   ├── pages
│   ├── styles
│   ├── graphics
│   ├── images

Remember you can get this generated for you by using the Yeoman generator, described above this section.

| Folder | Description | | ---------------- | ------------- | | source | This folder is the place for the hierarchical content files, being the markdown files for the content data as well as an associated config file written in yaml. The config file describes what kind of pagetype content will be rendered into. In the following illustration I'll elaborate a bit on this particular folder and how it could look. | | templates | Folder for templates in which the content will be rendered into. In here we have folders for master-files, component-files and pages which inherits from master. | | styles | The styling - using Sass | | graphics | Graphics that's supposed to be used to present the overall aesthetics of the site - this being icons in bitmap and vector files etc. | | images | Images used in content. |


Source folder file structure


I think this is best described using an example of a source-folder and a representation of what that source looks like in the final generated product.


Source


So if we have a source looking like this:

├── source/
│   ├── About us
│   │   ├── Subpage about us
│   │   │   ├── content.md
│   │   │   ├── config.yaml
│   │   ├── leftside.md
│   │   ├── rightside.html
│   │   ├── config.yaml
│   ├── Contact
│   │   ├── content.md
│   │   ├── config.yaml
│   ├── content.md
│   ├── config.yaml

| Filename | Description | | ---------------- | ------------- | | placeholder_name.md | Contains content for a placeholder, written in markdown. The filename must match a placeholder name inside crust. In this particular case {{ crust_placeholder_name }} | | placeholder_name.html | Contains content for a placeholder, written in html. This is for when you want to inject certain HTML controls inside your templates. The filename must match a placeholder name inside crust. In this particular case {{ crust_placeholder_name }} | | config.yaml | Contains configuration for how to merge the content of content.md into templates. Look below for a sample |

Let's look at the About us from the source example above as an example:

It has the following files associated:

├── leftside.md
├── rightside.html
├── config.yaml

This means that the template for this particular page should have the following placeholders: {{ crust_leftside }} and {{ crust_rightside }}

The content of config.yaml contains the following configuration:

---
template: page-about

And our templates should therefore have the following template-file inside it:

├── app/
│   ├── source
│   ├── templates
│   │   ├── ...
│   │   ├── pages
│   │   │   ├── about.html

Which contains the following markup:

{% extends '../master/layout.html' %}

<div class="row">
  <div class="col-lg-6">
    {{ crust_leftside }}
  </div>
  <div class="col-lg-6">
    {{ crust_rightside }}
 </div>
</div>

Now when we run it through the crust compiler we should end up with a product that merges our template above with the markdown transformed content from leftside.md and the raw html from rightside.html replacing {{ crust_leftside }} and {{ crust_rightside }} respectively.

If we generate the source-structure from before using crust, it will produce an output like this:

├── dist/
│   ├── About us
│   │   ├── Subpage to about us
│   │   │   ├── index.html
│   ├── Contacte
│   │   ├── index.html
├── index.html

The content of the dist-folder should be ready to ship to any web hosting provider possible and is now considered to be unattached to the crust framework. If you need to do changes, you should do them inside the source-folder, run it through crust again and re-upload the content of the dist-folder.

Please note that the source-folder itself has both content and config files associated to itself and will upon render be turned into the front page.


Custom variables


Sometimes you'd want to pass in custom variables for pages to be able to act on for presentational purposes. There's a special namespace reserve for this type of behaviour inside the config.yaml file for pages.

Let's say you have some sort of additional meta data for an article. This could be the name of the author, that you'd like to pass into the rendering. You could add this piece of information in the config.yaml file like this:

---
template: some-template
crustVars:
  author:
    name: John Doe
    twitter: http://twitter.com/JohnDoe
    

The crustVars object will be exposed upon generation of the HTML, so in your template you'd be able to react upon these information by doing something like the following:


<a href="{{crustVars.author.twitter}}">{{crustVars.author.name}}</a>

If the crustVars object is absent it will simply be ignored by the compiler.


Dynamic linking


Sometimes you would want to be able to link to a certain page from other templates.

In Crust you can do this by defining a permalink token inside the config.yaml for the page you want to link to, thereby making it possible to identify it from within templates.

config.yaml :

---
template: toplevel
permalink: my_link_token_for_this_page

To digest the link for this page, all you would need to do inside your templates would be:

some-template.html :

<a href="{{ crust__link_my_link_token_for_this_page }}">A link label</a>

And upon build, Crust will automatically put in the correct path for the page, making it completely unaffected by changes in folder renames and such.


Sorting children


Crust works with the file structure, so the default sorting of pages in the structure that's sent up to the templates for presentational interpolation will be the alphabetical order of the folders. You're able to override this default with an ordered array of all or some of the child node names in the config.yaml file.

So if you have a source structure that reads as follows:

├── source/
│   ├── Frontpage
│   │   ├── Subpage A
│   │   │   ├── content.md
│   │   │   ├── config.yaml
│   │   ├── Subpage B
│   │   │   ├── content.md
│   │   │   ├── config.yaml
│   │   ├── Subpage C
│   │   │   ├── content.md
│   │   │   ├── config.yaml

And you for some reason want to have an order that reads: Subpage B, Subpage A, Subpage C, you can add the childSort array in the Frontpage config.yaml file as follows:

config.yaml :

---
template: some-template
childSort:
  - Subpage B
  - Subpage A
  - Subpage C

If you just want the Subpage C first and don't really care about the order of the rest of the pages you could make do with the following configuration:

config.yaml :

---
template: some-template
childSort:
  - Subpage C

This will result in Subpage C being first in the order and the rest in their default order.


API


Options


| Name | Type | Default | Description | | ---------------- | ------------- | ------------- |------------- | | sourceFolder | string | | Path to source folder that holds hierarchical page structure | | templateFolder | string | | Path to where the page type template files are located |


Basic usage:


var crust = require('crust-io');

crust.compile(dir, { 
    sourceFolder : 'app/source',
    templateFolder : 'app/templates/pages'
});

Use with gulp


var crust = require('crust-io');

gulp.task('crust', function () {
	var sourceFolder = 'app/source';

	// the dir from which we should read the hierarchical page structure
 	var dir = path.join(__dirname, sourceFolder);

	return crust.compile(dir, { 
		sourceFolder : sourceFolder,
		templateFolder : '/app/templates/pages/'
	});
});

❤♥ Pentia ♥❤