staticy is a library designed to ease the development and deployment of websites which consist solely of static artifacts - usually HTML, CSS, and JS files - hosted on a "dumb" server with no backend logic, for example GitHub Pages.
staticy provides a development-time webserver that offers smart live reloading, smarter exception tracking, and more.
Once you're done developing,
staticy can immediately produce a flat list of files to deploy to your target server (or GitHub Pages
docs folder), eliminating the need for separate build scripts.
staticy is built around a few core concepts. Let's explain them at high-level, then dive into more details.
- A file provider tells
staticyabout which server files exist, and how to generate them
- Each server file in turn depends on zero or more local files through some transform
The distinction between a server file and a local file is critical.
A server file is a file that should be served to a browser.
A client file is a file that exists on disk.
For example, the client file might be a
.less file which is transformed into a
.css server file.
While there is often a one-to-one correspondence between server and client files, this isn't always the case. This documentation will always disambiguate between server files and local fils.
staticy doesn't know how your HTTP server is configured, you may need to inform it of certain configuration details.
HTTP servers will typically respond to a URL like
http://www.example.com/foo by loading
By default, if asked to render a path with no registered server file,
staticy will then attempt to load that path with
TODO: Implement some other behavior, somehow
HTTP servers must send correct MIME types in order for clients to render the content correctly.
staticy will send a MIME type corresponding to the file extension of the server file, or
text/plain if the file extension isn't a recognized one.
TODO: How is this otherwise configured?