🔹[EPIC] Add BOS to create-near-app

[thisisjoshford]

What

create-near-app should include an option for BOS decentralized front-ends.

Why

• To provide a quick scaffolding tool that meets existing expectations for front-end devs.
• To assist in onboarding developers to BOS by providing a basic project structure and a working demo.

Resources

How

### Related Issues
- [ ] https://github.com/near/create-near-app/issues/2104

[frol]

@thisisjoshford @gagdiez I would really consider baking it into bos cli: https://github.com/bos-cli-rs/bos-cli-rs/issues/44

I synced with @gagdiez recently on the create-near-app topic, and shared my belief that create-near-app is not doing any good for developers and we’d better focus on the dedicated tools (cargo near new, bos project new, guides on how to integrate NEAR into frontend and backend frameworks)

[gagdiez]

to give visibility to our talk with @frol I will also include what I said.

When create-near-app was first released it was the only way to scaffold a project. Fast-forward to today and two important things have happen: (1) tooling in the ecosystem has matured, and (2) the focus on "what is a NEAR app" has shifted from a NEAR app is a smart contract with maybe a frontend to a NEAR app is something that uses Web3 Components and maybe a smart contract.

Because of this, I agree that, in the future, we might want to substitute create-near-app for another series of tools (some tools for creating contracts?? and a tool for creating frontends??).

However, right now those tools are not there yet, and the effort on changing the documentation and creating tutorials is higher than the effort to just add a new frontend type to create-near-app.

Therefore, I am going to make one last change to create-neap-app that (1) separates creating contracts from creating frontends, and (2) adds a Gateway frontend. After that, we need to have a call with key members of the ecosystem and make some decisions on scaffolding tools.

[elliotBraem]

From the NEARCON hackathon, a team made a quick create-bos-app. It initializes an app with the bos-workspace structure so devs just need to run create-bos-app, cd into the project, and run bw dev. Now their widgets are being served and can be accessed after setting /flags.

It works, but isn't feature rich. And I do think that ideally, it doesn't need to be a separate package and could be merged into create-near-app or bos-workspace as a bw init command.

The project board for bos-workspace can be found here.

At least 22 developers have used the workspace and it has been used to deliver BOS apps like Create, Genadrop, Magicbuild, Potlock, and more. Every project in the Liberty DAO Hackoween hackathon used it and Near Builders provided support for many projects during the NEARCON hackathon who used it, too.

For context, the bos-workspace replaces bos-loader with a cleaner replacements strategy and a /build folder allowing opportunity to integrate Typescript transpilation, module building, etc..., and wraps around bos-cli-rs to allow managing multiple apps w/ different deploy accounts in one repository, enabling the ability to deploy specific directories for different purposes, and deploying JSON data to the social db (not limited to widget metadata).

I think it would be great for us to collab there, or potentially, evolving it into a fully-featured, all encompassing "near-workspace".

[gagdiez]

@elliotBraem please notice that the basic gateway created by create-near-app does not include the concept of flags for Component development. This was a conscious choice since addingflags since:

1. Increases the complexity, i.e. we need to explain more things in our tutorials
2. Is used for development of components, which we will guide users to do somewhere else (e.g. jutsu, near.org, vscode, etc).

Therefore, create-bos-app and bos-workspaces do not necessarily belong here, but they might have a place in the documentation.