Closed jonschlinkert closed 9 years ago
In the latter, it seems we would just be extending the options with each middleware, similar to how .assemblerc.yml
works. so I expect they would have to be called in the order specified in the array.
:+1:
This should be simple enough to do the first one. I'm not sure if we could do the first and second unless I'm assuming each middleware object will always look like the options:
middleware: [
{
structure: ':year/:month/:day/:post/index.html',
permalinks: {
...
}
}
]
I think we need to have a spec for getting/setting values with the context. if we spend some time explaining how/when certain values can be set during the build, then at least the logic and conventions for this kind of thing will be easier to standardize and generalize. (for anyone reading, this won't be easy.)
this is possible with the 0.6 release of assemble
@doowb, I'd like to add a middleware option that essentially takes an array of middlewares. Each middleware would just be replacement patterns. So instead of this:
you could do this:
Or ideally middlewares would be able to define all options, so if you can use the middleware's defaults, you could just do:
But the latter isn't a have-to-have. I'm not as familiar with the Strings lib as I'd like to be, so I'm not sure what needs to be done to implement this. @doowb can you take a crack at it?