Skip to content

Milestones

List view

  • Due by March 17, 2014
    6/6 issues closed
  • No due date
    8/8 issues closed
  • #### SCSS - Sass’ SCSS syntax will be added as a **CSS** superset. - Should have the extension `.scss`. - Using `.css.scss` ext will be a way to compress a vanilla `.css` file. `.css.less` also works for this purpose. ##### Goals Sass is implemented in C and therefore a compilers is currently needed to install the `node-sass` library. Harp will go to whatever lengths reasonable to avoid this dependency by distributing the binaries for the most popular platforms. The compile step will only be done if needed to run on host platform but the majority of use cases should not require this step. In other words, `npm install harp -g` should just work on a fresh install of OSX and Windows.

    No due date
    2/2 issues closed
  • ## Making Harp apps mountable The goal of this release will be to make harp apps completely portable. This will make it trivial to tack a blog or whatever onto an express/connect server. ### API #### harp.mount(mountPoint*, harpPath) if you would like to mount an application at the "/docs" route just add that as your **mountPoint** ```javascript var docsPath = __dirname + "/docs" app.use(harp.mount("/docs", docsPath)) ``` The **mountPath** is optional. If you would like to use harp as your asset pipeline, just omit the **mountPath** and point it to your harp app.... ```javascript app.use(harp.mount(__dirname + "/public")) ```

    No due date
  • Currently harp.json files take a `globals` object that is assigned to the a `globals` key when passed in the template. ``` { "globals": { "name": "Brock" } } ``` and in the template... ``` <h1><%= globals.name %></h1> ``` We will be changing this to the following. This has many benefits from a creative standpoint. ``` <h1><%= name %></h1> ```

    No due date
    1/1 issues closed
  • #### TypeScript **note** this milestone has been put on the back burner after investigation of the TypeScript library. - TypeScript will be added as the recommended **JavaScript** superset. - TypeScript will have the extension `.ts`. - Using `.js.ts` ext will be the recommended way to compress a vanilla `.js` file.

    No due date
    1/1 issues closed
  • Layout engine could use some minor improvements. #### 1) Implicit layout behaviour Layouts should walk the directory tree by default looking for `_layout.xxx` in each directory until it hits the public directory. (specifying a layout file in _data.json) will be how you override this behaviour. #### 2) Overrides should be a relative path to the template file Specifying a layout in `_data.json` will be how to override the implicit layout behaviour and this file path should be relative to the template file. This makes sense because the `_data.json` file lives where the template file lives. #### 3) Layout file opt-out. Specifying a `"layout": false` in the `_data.json` should not use a layout file and `"layout": true` should just work as the default behaviour.

    No due date
    3/3 issues closed
  • The goal of this release will be to make Harp suitable as disposable web server for easy local development. Currently harp has a format similar to frameworks such as rails or express with a `public` directory in the root of your project which is where static assets are served out of. This is convenient for most projects that have other assets that you do not wish to be served. root/ |- harp.json +- public/ +- (public assets served from here) This could be improved upon by allowing harp to work as a server that makes the root directory public (note the _harp.json file begins with underscore in this case). root/ |- _harp.json +- (public assets served from here here) The default behaviour will be the latter with the root becoming the public directory. When a `harp.json` (no underscore) file is present, the web server will look for a `public` directory to serve the assets out of.

    No due date
    4/4 issues closed