I need some help figuring out a better way for local development. I'm building off of the context from this [post here](https://near.social/mob.near/widget/MainPage.N.Post.Page?accountId=efiz.near&blockHeight=115074872). The below image shows how bos-workspace serves widgets to the gateway for local development. Alternatively, [bos-loader](https://github.com/near/bos-loader) uses flags via local storage (to get the widget server address and then fetches the entire map. While [bos-workspace](https://github.com/nearbuilders/bos-workspace) still supports flags, it prioritizes an approach that replaces a `%ENV_CONFIG%` in the target gateway's index.html, which is then extracted by a hook in the gateway, so it can hook up a web socket connection to listen in on changes. ![bos-workspace](https://ipfs.near.social/ipfs/bafkreidvdbc74pcmznrin3ettwn6od7624fkxe44ye7la2zvpsrijoca2e) (you can look at this diagram & draw on it via this [collaborative canvas](https://www.tldraw.com/r/rw9W7SsJnejDFsWFznT5K?v=-1436,-668,2572,1414&p=YCvTXo99hlLvsexr4Mein)) There's a few issues with this... 1. bos-workspace provides a `--gateway` flag that let's you can provide a pathway to your own `dist` to use for local gateway, but in order for this web socket connection to work, the target `dist/index.html` must have %ENV_CONFIG% in it, and the web component installed in the `index.html` must have the useRedirectMap hook that reads from this replaced config and listens to the changes. Do we want this dependency in every near-bos-wc? 2. While `%ENV_CONFIG%` get's replaced during development, you have to comment this out when you want to deploy to production, or else the build fails. 3. bos-workspace has a `bos.config.json` (for alias replacements) AND near-bos-webcomponent has a `bos.config.json` (for specifying default widget to deploy to web4... this could also have a link to dist stored on ipfs that should be deployed, e.g. someone wants their web4 deploy to have https://tldraw.near.page). These should share the same bos.config.json. I think the ultimate goal is the ability to develop widgets locally, specify the gateway bundle you want them to live in (or default), and then be able to deploy these widgets to social.near + deploy a reference to gateway bundle to web4 contract, then web4 uses the "index' widget you specify. Also don't want to redeploy an entire bundle just to specify a different root widget... maybe this is where @jsinrust.near could be very helpful. What do you think? #build #question