pandastrike / haiku9 Goto Github PK

View Code? Open in Web Editor NEW

8.0 8.0 2.0 1.75 MB

Static Site Publishing

License: ISC License

CoffeeScript 91.55% JavaScript 0.11% Handlebars 8.34%

haiku9's People

Contributors

Stargazers

Watchers

Forkers

strogo diminish7

haiku9's Issues

"h9 publish" Should Look at Content Type

It's possible for a file in a repo to change content type without changing anything within (which is detected by the md5 hash). Add a check for content type in the sync.

Correct Font MIME Type

In work on ps.com, it appears fonts are being served as html/text, when it should be application/font-woff.

server should ignore query parameters

come up with a developer-friendly equivalent for price class

Maybe we can have an alternative attribute named coverage or something like that, with values like global or regional. Alternatively, we can just default it, which I think we do already.

Implement renderToFile

I forgot to add this. We can use the path, the key, and the format to figure out what to render. These are all already asset properties.

possibly get extensions from filenames?

I used to be a big fan of this idea, where you establish a pipeline via filenames. So:

foo.html.jade

would generate foo.html.

add tests for remaining build tasks

images, pass through assets, blog pagination, browserify bundles…

integrate grammar and spell-checking into publish process?

make it easier to add Stylus plugins

Bail Out After Detecting a Noop Sync

Support for handlebars (via panda-template)

Refactor to avoid readFile for cached Jade templates

We should avoid readFile when a template is already cached.

Also, check if marked and stylus support caching; if not, implement our own caching.

Implement caching compiled functions

Even though Jade implements caching, its simplistic. haiku9 should implement LRU caching of compiled functions.

Determine a Policy for Files Larger than 5 GB

Currently, objects within an S3 bucket must be less than 5GB in size. If you attempt to upload a bigger file, the AWS SDK automatically splits it into chunks that get stored as separate objects. This complicates both static website delivery and MD5 integrity checks during S3 sync.

Currently, H9 takes no steps to handle this edge case. Should we acknowledge that files that large are unlikely to be used and disallow them? Or should we accommodate them?

`npm test` => all tests fail

> [email protected] test /vagrant/haiku9
> coffee test/index.coffee

 Haiku9 static-site generation
   Compile Stylus files AssertionError: File site.css not built
 Haiku9 static-site generation
   Passes through json files AssertionError: File manifest.json not built
 Haiku9 static-site generation
   Compiles Jade files AssertionError: File index.html not built
 Haiku9 static-site generation
   Compiles CoffeeScript files AssertionError: File site.js not built
 Haiku9 serve task
   Starts a local server on the default port AssertionError: Server did not respond
 Haiku9 static-site generation
   Passes through xml files AssertionError: File browserconfig.xml not built
Beginning task 'build'...
Beginning task 'survey'...
Beginning task 'survey/pass-thru'...
Beginning task 'build'...
Beginning task 'survey'...
Beginning task 'survey/pass-thru'...
Task 'survey/pass-thru' completed in 394ms.
Beginning task 'build'...
Beginning task 'survey/image'...
Beginning task 'survey'...
Beginning task 'survey/pass-thru'...
Task 'survey/image' completed in 6ms.
Beginning task 'survey/stylus'...
Task 'survey/stylus' completed in 5ms.
Beginning task 'survey/jade'...
Beginning task 'data'...
Task 'data' completed in 32ms.
Task 'survey/jade' completed in 40ms.
Beginning task 'survey/coffee'...
Task 'survey/coffee' completed in 3ms.
Beginning task 'survey/markdown'...
Beginning task 'build'...
Task 'survey/markdown' completed in 2ms.
Beginning task 'survey'...
Beginning task 'survey/posts'...
Beginning task 'survey/pass-thru'...
Task 'survey/posts' completed in 1ms.
Beginning task 'survey/bundle'...
Task 'survey/bundle' completed in 5ms.
Task 'survey' completed in 465ms.
Task 'build' completed in 484ms.
Task 'survey/pass-thru' completed in 182ms.
Beginning task 'survey/image'...
Task 'survey/image' completed in 8ms.
Beginning task 'survey/stylus'...
Task 'survey/stylus' completed in 2ms.
Beginning task 'survey/jade'...
Beginning task 'data'...
Beginning task 'build'...
Beginning task 'survey'...
Beginning task 'survey/pass-thru'...
Task 'data' completed in 14ms.
Task 'survey/jade' completed in 15ms.
Beginning task 'survey/coffee'...
Task 'survey/coffee' completed in 1ms.
Beginning task 'survey/markdown'...
Task 'survey/markdown' completed in 1ms.
Beginning task 'survey/posts'...
Task 'survey/posts' completed in 1ms.
Beginning task 'survey/bundle'...
Task 'survey/bundle' completed in 7ms.
Task 'survey' completed in 218ms.
Task 'build' completed in 229ms.
Task 'survey/pass-thru' completed in 200ms.
Beginning task 'survey/image'...
Task 'survey/image' completed in 6ms.
Beginning task 'survey/stylus'...
Task 'survey/stylus' completed in 2ms.
Beginning task 'survey/jade'...
Beginning task 'data'...
Task 'data' completed in 10ms.
Task 'survey/jade' completed in 13ms.
Beginning task 'survey/coffee'...
Task 'survey/coffee' completed in 1ms.
Beginning task 'survey/markdown'...
Task 'survey/markdown' completed in 1ms.
Beginning task 'survey/posts'...
Task 'survey/posts' completed in 1ms.
Beginning task 'survey/bundle'...
Task 'survey/bundle' completed in 2ms.
Task 'survey' completed in 228ms.
Task 'build' completed in 237ms.
Task 'survey/pass-thru' completed in 220ms.
Beginning task 'survey/image'...
Beginning task 'build'...
Beginning task 'survey'...
Beginning task 'survey/pass-thru'...
Task 'survey/image' completed in 9ms.
Beginning task 'survey/stylus'...
Task 'survey/stylus' completed in 0ms.
Beginning task 'survey/jade'...
Beginning task 'data'...
Task 'data' completed in 5ms.
Task 'survey/jade' completed in 6ms.
Beginning task 'survey/coffee'...
Task 'survey/coffee' completed in 1ms.
Beginning task 'survey/markdown'...
Task 'survey/markdown' completed in 2ms.
Beginning task 'survey/posts'...
Task 'survey/posts' completed in 0ms.
Beginning task 'survey/bundle'...
Task 'survey/bundle' completed in 4ms.
Task 'survey' completed in 252ms.
Task 'survey/pass-thru' completed in 156ms.
Beginning task 'survey/image'...
Task 'build' completed in 259ms.
Task 'survey/image' completed in 2ms.
Beginning task 'survey/stylus'...
Task 'survey/stylus' completed in 2ms.
Beginning task 'survey/jade'...
Beginning task 'data'...
Task 'data' completed in 5ms.
Task 'survey/jade' completed in 8ms.
Beginning task 'survey/coffee'...
Task 'survey/coffee' completed in 1ms.
Beginning task 'survey/markdown'...
Task 'survey/markdown' completed in 1ms.
Beginning task 'survey/posts'...
Task 'survey/posts' completed in 0ms.
Beginning task 'survey/bundle'...
Task 'survey/bundle' completed in 1ms.
Task 'survey' completed in 174ms.
Task 'build' completed in 183ms.
Task 'survey/pass-thru' completed in 80ms.
Beginning task 'survey/image'...
Task 'survey/image' completed in 2ms.
Beginning task 'survey/stylus'...
Task 'survey/stylus' completed in 1ms.
Beginning task 'survey/jade'...
Beginning task 'data'...
Task 'data' completed in 3ms.
Task 'survey/jade' completed in 4ms.
Beginning task 'survey/coffee'...
Task 'survey/coffee' completed in 1ms.
Beginning task 'survey/markdown'...
Task 'survey/markdown' completed in 1ms.
Beginning task 'survey/posts'...
Task 'survey/posts' completed in 0ms.
Beginning task 'survey/bundle'...
Task 'survey/bundle' completed in 1ms.
Task 'survey' completed in 91ms.
Task 'build' completed in 97ms.

getting started tutorial

Use separate, simple fixture sites for tests

Right now, the build test runs against examples/simple-site, which includes testing jade, coffeescript and stylus templates all in one test.

First, that makes our tests rely on the example site, so if we change the example site for documentation / quick-start purposes, it may break our tests.

Second, it lumps all building tests into a single build. Does it make sense to have one fixture site to test jade, one to test coffeescript, one to test stylus etc? This doesn't seem like a huge deal right now since those three things cover separate concerns, but if we add a markdown test, and start adding additional asset types, the single simple site will get cluttered and hard to manage.

Cutting off the last page of blog posts

Make blog settings optional in H9

Basically, don't run the blog tasks if the settings aren't there…

make apex forwarding an option?

Ex: blurb9.com forwards to www.blurb9.com.

Low priority, in any event.

support redirects via files

Since S3 supports redirects, we can introduce .link files that contain URLs. The corresponding asset type is a pass through. When published, we'll add the 301 for the corresponding URL to the URL in the link.

add image optimizer helper

This should include optimization, compression, and responsive image support.

Create default middleware

Although you can create your own custom middleware, we could provide a nice default.

support custom tasks

Ex: post-formatting?

Set DNS Records with Upsert, not Create-Delete

Add CoffeeScript Formatter

Create Jekyll style CLI

We can build on the middleware (#3) to create a simple CLI to serve up assets or compile them.

show progress during publish (sync)

Could (initially) be as simple as:

15% done...
20% done...
...

Make `region` Config Field Optional

Currently, H9 makes you specify the region for the bucket storing your site. There's not a strongly compelling reason to do this, other than it made things easier during development. If you don't use the correct region when querying against a bucket, you get a 301 error that prevents syncing.

Work should be done to make the region field optional.

Allow CloudFront Distributions to Forward Cookies and Query String Parameters

Explicitly set MD5 hash for sync

Coffeescript "require" support

Or some equivalent which supports modular code broken into multiple files, compiling them into a single file during the pipeline build?

tests always pass, even when they should fail

To reproduce: change site.css to site.anything in stylus_spec, and then run npm test. It will pass against the current master branch.

Not sure if related to #60, #61 or not.

support data files

Not just for loading template data, but possibly for accessing from the site itself.

support non-HTML extensions

should environments be a dictionary instead of an array?

The name of environment could be the key. Not a high-priority, just slightly simpler.

Make the port a configuration setting :/

Address Bucket Existential Bug

Whenever creating a new bucket, sometimes you get a bucket does not exist when you try to sync with it. Right now I have a 5 second wait, but that's super hacky and doesn't always work. Look into confirming the bucket's existence after creation.

Verify implementation for passing in contexts

This hasn't even been tested informally. The use case is compiling a Jade template with a collection of blog posts.

Define environments for publish

Example:

s3:
  domain: pandastrike.com

  region: us-west-2

  web:
    index: index
    error: 404

  environments:
    staging:
      hostnames:
        - staging
        - test
      cache:
        expires: 60 # 1 minute
    production:
      cname: true
      hostnames:
      - www
      cache:
          expires: 1800 # 30 minutes

$ h9 publish staging

We can define an environment called default to be used if none is specified.