Jon-Kyle

Totally. I was thinking something like this could be useful. ```js var pages = page().pages().filter(name => name === 'jon').paginate(2, 10).toArray() ``` But yeah, either way.

Can now start messing with this by using the `next` tag on npm. ``` npm i nanopage@next --save ```

A fun new one. Both the `page()` and `file()` methods accept a [glob](https://github.com/isaacs/minimatch) in addition to a path (string) and state (obj). ```js var images = page('../*.jpg').toArray() ```

Relative urls have also been introduced. ```js var parentTitle = page('../').value('title') ``` This has been published as `next2` to npm under the `@next` tag.

something closer to the second option might be right, as i’m unsure how we’d handle that with a heavy chain such as: ```js page('/example').pages().sortBy('date', 'asc').first().find('wtf').v() ``` that `Object.keys` solution seems...

that’s interesting. how does this work if we’re wanting to check global vs. local? for example `page('child-page-example')` vs. `page('/root-page-example')`.

ah word, i meant root or relative, i guess. i think you’re right in that now we no longer have to compare against a `pages` object, so we can do...

yeah 100%! current structure is sort of left over b/c i’m a dummy who can’t architect something without doing it first.

oh shit, this is some dark magic. definitely interesting. i like the cleanness of it simply being a class/prototype, but one reason to possibly accept `opts` like your last example...

Also running into this one. @maxKimoby, perhaps create a pull request for your fork?