new "boot" hook?

[leeoniya]

if options need to be tweaked by plugins, then init (effectively didInit) is not the place to do it - it's too late. yes, it's a somewhat counter-intuitive but logically consistent. we can add another, earlier hook to mutate passed opts (effectively willInit) that will fire basically at the top of the constructor - we can steal the linux boot process terminology and call it boot(self, opts), which should return adjusted opts. this will be a bit tricky since the return of each boot hook will need to be passed into the next boot hook - which is not how fire() currently works, and i'm not a fan of complicating it. we can simply, expose u.opts and assume that boot hooks will mutate it directly, which is not great but would work.

[1] https://www.tldp.org/LDP/intro-linux/html/sect_04_02.html

[ldstein]

Maybe in addition to hooks, a plugin can expose a configure(opts) function. Can then be handled outside of the standard fire() behaviour. Is it a special enough case to be handled differently?

function myPlugin(){
	return {
		configure: (opts) => opts.cursor.x = false;
		init: [() => {}],
		setCursor: [() => {}]		
	}
}

[leeoniya]

yeah i think you're right. its opts pass-along behavior is different enough, and i see no value in passing in self to it, like hooks get.

i'm not super excited about it living alongside hooks, tho. and honestly i don't like the implicit assumption that the returned object from a plugin is a hooks config since there's no typehinting in the codebase.

maybe the plugin format shod be tweaked to be a bit more explicit with the return being

{
  opts: prevOpts => nextOpts,
  hooks: {
    init: [...],
    setCursor: [...],
  }
}

it's more future-proof, too. e.g. things like version can be added later.

another tweak might be to remove hook arrays in plugins, there's no need for them:

{
  opts: prevOpts => nextOpts,
  hooks: {
    init: u => {},
    setCursor: u => {},
  }
}