Odd behaviour with marked renderer override
Bartvds opened this issue · comments
I'm trying to use the renderer option for marked: https://github.com/chjj/marked#renderer
I expects an instance with some methods, like from new marked.Renderer().
But the plugin errors somewhere in marked, it cannot find methods on the instance I set in the markedOptions.
I investigated and it looks like something is replacing my instance with another object? A model with has/get/set methods?
All options properties get passed but methods get removed.
Can you run docpad with the -d flag, so docpad generate -d or whatever, and then provide us with the docpad-debug.log file. Cheers.
Good call. It was not docpad that did this.
Because I now feel silly for reporting this here you get the full info, may it save you some time solving other reports:
I use a grunt wrapper to run docpad (so via the docpad API), but after your ask for debug dump I could not find how to use debug mode in API. So I got the global docpad command and tried that.. and that totally worked fine.
Oops. So what happened?
You know grunt right? You know how multi-tasks targets have a feature to use a .options property that you share between multi-tasks targets (as a default), and then can override some properties per-target?
I require()-ed the docpad configuration and used it as default option, and set extra vars on the production target. So far that worked fine.
But apparently grunt does some borked deep-clone on the default options object when it bakes the per-target options, and that destroys prototype based objects (like the marked.Renderer instance).
I've used grunt for a long time but this was new to me.
Sorry for not spotting this earlier, I'm new to docpad so I blamed to soon.
I wanted to report this to grunt issue tracker, but somebody already reported it: gruntjs/grunt#1106
Funny enough also with marked.Renderer.
They note this behaviour is fixed in grunt v0.4.5 (I tested and it is true, I had v0.4.4 when this happened).