Would some sort of "Context" for the build process be useful?

[tylersayshi]

And if yes, how might we represent this?

Why I think this may be useful

1. Knowing things like what type of deploy we are building for is useful information throughout the build lifecycle. As we get many levels down the callstack it becomes increasingly difficult to know what we are building for. Adding a bunch of parameters to each function all the way down feels like a band-aid and reminiscent of prop-drilling.
2. Storing the waku config selections would also seem really helpful to have access everywhere in the build process

I plan to follow up here as I think about this more, but wanted to put my initial thoughts down and open this idea up for some feedback.

Edit: I learned that there actually already exists a waku.config.ts (I can look into adding this to the docs page if it is ready?)

[dai-shi]

Thanks for opening up a discussion.

My original idea was, waku/router is independent from build process (hidden behind unstable_defineRouter). However, when I introduced fs-router, I had to add buildConfig in a hacky way, which made me realize that my original design is too limited.

Now, I'm thinking about exposing build process more, including something like build config and probably build context. I'll work on it once we finalize v0.21.0.
(There are also other ideas/issues that I need to change my original design. Stay tuned.)

As for waku.config.ts, we plan to revamp it too: #763
But it will come after v0.22.0.
I think it's fair to have current waku.config.ts usage in ./docs, as long as we note it as "experimental".

[dai-shi]

#860 introduces "build options" (I want to avoid using the word "context")