You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After setting up multiple bos-workspaces across the ecosystem, I've encountered some recurring feedback.
Typically, bos-workspaces have not been used as monorepos handling multiple different apps and will instead use one app + deploy accountId, which will be setup in a Github Action
A common flow I've had to do is the following:
For bluntdao, I needed to initialize a bos-workspace, pull in existing widgets, then set up the workflow
mkdir bluntdao-components
cd bluntdao-components
mkdir apps
mkdir apps/bluntdao
mkdir apps/bluntdao/widget
touch apps/bluntdao/bos.config.json
touch apps/bluntdao/widget/hello.jsx
cd apps/bluntdao
bos components download bluntdao.near
// this downloads all bluntdao components to a /src directory
// now we need to move them all to the widget directory
mv src/widget/* widget/.
npm init (create package.json)
npm install bos-workspace
// create npm run dev and npm run build in package.json -> bw dev, bw build
// copy over github workflows
// modify github workflow working directory to be the app name (bluntdao)
npm run dev
And then sometimes, if there are multiple apps, such as genadrop; instead of dedicate different accounts for each app, they add a prefix like in genadrop, so there are prefixes GenaDrop and CPlanet, and so you can have a structure that looks like this:
apps/bluntdao/widget/bluntdao/hello.jsx
I think the multi-app flow is powerful, and maybe GenaDrop and CPlanet should be following it rather than what they are doing now deploying to the same account
But it is very common to set up a github repository for only one app + to only configure one deploy and signer account for it for the Github Action; and so the deep directories repeating the same app name can be confusing.
I feel like both should be supported, especially considering the context of #25 and #19; but it may mean changing default behavior or reducing a layer; food for thought
The text was updated successfully, but these errors were encountered:
This definitely need to be addressed, in my opinion the best approach is to let the apps location dependent on bos.config.json location, this way bos-workspace will be less opiniated, and if implemented correctly it will be still compatible with the current projects too.
After setting up multiple bos-workspaces across the ecosystem, I've encountered some recurring feedback.
Typically, bos-workspaces have not been used as monorepos handling multiple different apps and will instead use one app + deploy accountId, which will be setup in a Github Action
A common flow I've had to do is the following:
For bluntdao, I needed to initialize a bos-workspace, pull in existing widgets, then set up the workflow
And then sometimes, if there are multiple apps, such as genadrop; instead of dedicate different accounts for each app, they add a prefix like in genadrop, so there are prefixes GenaDrop and CPlanet, and so you can have a structure that looks like this:
apps/bluntdao/widget/bluntdao/hello.jsx
I think the multi-app flow is powerful, and maybe GenaDrop and CPlanet should be following it rather than what they are doing now deploying to the same account
But it is very common to set up a github repository for only one app + to only configure one deploy and signer account for it for the Github Action; and so the deep directories repeating the same app name can be confusing.
I feel like both should be supported, especially considering the context of #25 and #19; but it may mean changing default behavior or reducing a layer; food for thought
The text was updated successfully, but these errors were encountered: