Bazyli Brzóska

Since `module` is literally the property above (`'@niieani/beemo-build-tools'`), couldn't Beemo itself try resolving it relative to it, aside from looking at installed node_modules?

OK, gotcha. Thanks for the quick reply. Aren't Scripts being loaded relative to the provider module already today? Couldn't Drivers just use the same resolution mechanisms? https://github.com/beemojs/beemo/blob/665f37ba8d6b8555bc5c67bdca46702dc042688a/packages/core/src/routines/RunScriptRoutine.ts#L98-L110 If absolute path...

> But having the consumer provide the merge API may be viable. Did you mean the provider - i.e. consumer configures overrides as it pleases, and provider handles the merging?...

I see. My thinking is this could also be set as the default strategy by the driver? This way the flow is IMO most transparent: - the provider's job is...

@hayes not sure if you read my first comment fully, but that's exactly what I did. But since it's a workaround, it needs re-implementing of the same logic every time...

Good to know! Anyhow, do you think it would be valuable to create something built-in to deal with this @milesj? I can take a stab at a PR, just want...

> The biggest issue I ran into was that there isn't a great way to access the driver specific merge functions at the time when the config files are executed....

I understand this @milesj, my question is about the reason why we couldn't add Beemo into the evaluation phase? It's initiated outside of Beemo, but is there a reason why...

@milesj by initiate I mean make `process.beemo` available for the tool, complete instance and populated with the configuration from the `.config` directory

Oh, nothing as fancy as that. I wouldn't even know if that's possible without corrupting the process 😅 I see two ways this could be done, both assume the tool...