cbaatz / knit Goto Github PK

Only load/include compilers for which the required libraries are available (require 'name' does not throw error and version is acceptable). That way, we could add compilers without bloating dependencies.

Documentation is severely lacking after the rewrite (version 0.8).

Don't just allow mime-type header, but any header. If the second argument to the put callback is a string, assume mime-type, if object, assume header map.

Some temporary files created by Emacs are found in the directory but can't be read by Node.js, so test for existence:

ENOENT, no such file or directory 'scripts/views/.#main.js'

Drop prefix underscore and make knit.coffee / knit.js the standard name for config files, but still allow .knit.coffe / .knit.js.

To help with getting started, create a repository with example uses. So people can get something working and playing with it by simply:

1. Installing knit and knit-common.
2. clone the example repo
3. knit serve

The example repo should have one root level knit.coffee file with a basic example, then subdirectories with more specialised examples.

Clean up the format, indentation, and content of the status messages that Knit displays to the user.

It should be possible to specifying overlapping nested routes:

'/js/': {'hello.js': handler}
'/js/': {'world.js': handler}

Currently only /js/world.js is served.

Similar to upload, use async for handling the writing queue.

npm install git://github.com/cbaatz/knit.git

An init command would help create static files useful for development. This might be a template for knit.coffee or a useful JavaScript library. Example usage might be:

knit init requirejs ./libs/require.js
knit init jquery-min ./libs/jquery
knit init base-app

It's some kind of mapping from a name to a file that gets read or downloaded. Exactly how it should work (using versions, tags, or similar for files, or specifying full directory structures) needs to be worked out.

Allow users to specify ad-hoc compilers from the config file. Probably also use this to parameterise existing compilers (e.g. mimetype for string/file).

If compiler throws error, catch it to avoid having to restart Knit.

To allow caching later, we might not want to reload the config files on each request; instead we might want to reload config files on an interrupt signal (SIGQUIT / Ctrl-D say) to Knit. Alternatively when a special URL is requested (/reload/).

Not convinced this is sensible, but could go up directory tree to find the knit file. Then we could do knit serve from any folder in the project. Would need to set $PWD correctly.

Change usage of "config file" to the more correct "resources file" in comments and docs.

Something that allows us to control verbosity would be nice.

Only include those modules that the selected main source file actually depends on. (Dependency does something like this).

If user specifies an --action command line parameter, ignore this and warn user that action is a reserved name.

For string and file compiler in particular.

Have writer create folders as necessary; currently it requires that folders already exist.

Instead of passing the actual HTTP response/file write streams to handlers, create a Knit specific writeable stream that can be created from an HTTP response or file stream. This is neater and allows us to add Knit specific functionality to the stream.

Expect the routes export in resource files to be a function (parameters, log) { return <routes>; } instead of an object. Requiring a resource file should have no immediate effect. Allow resource files to export a description so we can list all available resource files with their descriptions. This also allows us to remove the knit global variable. Could allow routes export to alternatively be a routes definition object that can't access the knit parameters.

For example, handler.directory('./non-existent') gives the counter-intuitive error that "no config module found".

Server option to strip off query string parameters from URL before matching local resources (but pass full to proxy if no match).

It should be possible to serve files from directory paths such as /something/. Now, these get rewritten to /something (i.e. loses the trailing slash).