Gerrit Birkeland

This is working as expected for mixed options. Mixed options could be objects, numbers, strings, or even a function... for this reason, TypeDoc performs no processing on them. Your plugin...

I would instead recommend: ```ts app.options.addDeclaration({ ..., default: {} }) // no real point including defaults here // later... const options = { foo: "a", bar: "b", ...app.options.getValue("opt") } ```...

I'm not really opposed to adding a new option type for nested options (how does it merge? don't want to add a new dependency, is `Object.assign` good enough? nested? does...

I think both of the proposed options are making this more complicated than it needs to be. A non-breaking way of introducing this behavior that I'd rather go for is:...

> Modifications to any and all options would persist into run(). They would only expect this if they had not read the [overview](https://typedoc.org/guides/development/) of how typedoc works. That is not...

Plugins may add readers to the options object, so can technically modify values there... I agree the event at the end of bootstrap is a good idea. > but this...

You have the right idea - however, unfortunately due to the architecture of some of the other plugins (GroupPlugin is one of them), removing reflections after the onBegin method will...

That could work as well - however that means that the categorization logic would have to happen earlier - instead of in the resolve event.... I'm not completely against that.

I spent a few hours today trying to get the reflection removed event to work - this is trickier than I anticipated... TypeDoc is really bad about storing data in...

I never ended up pushing any of the changes for the removal event. There are more architectural difficulties than I realized. 1. If removal can happen after the resolve step,...