search

motion / orbit

💫 unifying force
8 stars 1 forks source link

⚒App Development CLI #731

Closed natew closed 5 years ago

natew commented 5 years ago

Starting a ticket for tracking progress of the CLI until it's ready for beta launch. This includes the following high level features:

Inspiration would come from VSCode and how it handles it's package ecosystem, as well as create-react-app and others which in general try and protect you from configuration while giving you a great development environment. My general ideas are as follows.

  1. Leverage npm as much as possible. But avoid the pain of managing it all.

Apps would be created with a package.json, they would have an orbit-myapp style name. They would then import the orbit packages that each app uses. This would be something like @orbit/kit, @orbit/data-kit, and @orbit/ui.

Behind the scenes we'd build the app initially using our webpack configuration. See @mcro/build, which can become @orbit/build. This would be totally inside the cli, and just run behind the scenes. To me, the less they have to do the better here. The less configuration we have to expose as well. Basically for the beta all we want is to drop them into VSCode and give them a well-typed setup. Most of the focus should go into making the actual flow from Edit => Develop => Fix errors => Publish smooth, while removing as many foot-guns as possible for developers.

  1. Don't include everything to start.

We don't need a testing story, or a way to eject, or any sort of features outside of being inside Orbit. We'd rather invest extra time we have into making the apps themselves powerful, and getting the work/publish/deploy story down really well.

  1. Integration with git

This is something we should allow, but to start I'm hoping we can keep it simple.

Prior art:

Monorepo style

One idea is to have each space have a monorepo:

~/flint
  .git
  .tsconfig.base.json
  ... other configuration
  /myapp
    package.json
    main.ts
    tsconfig.json (if we can hoist this, do so)

Something as simple as this should work. We can then take advantage of putting most configuration a level above your apps, and most importantly, we can manage it all as one big monorepo in git. No need to manage multiple per-app.

Now, there are concerns here. What if you want to publish these packages into their own github repo with nice versioning? It's a good question and something I don't have a great answer for other than this:

We are not focused on a public app store to start. So from a time-use perspective, this really helps us with just solving "teams working together privately", and lets use get to market there very quickly. It also doesn't prevent anyone from publishing their packages, it just prevents easily having them in their own separate repo. I'm open to alternate ideas here that ideally simplify even further, but maybe have some benefit.

Individual package style

This is what Flipper does, which is just have a config file that points to anywhere. I don't like it for two reasons:

But it's worth considering perhaps some sort of hybrid here.

natew commented 5 years ago

One desire. I’d like to be able to work on apps without setting up too much.

I know that pointing at a Github repo is easy for most developers, but it just doesn’t feel great to me. It’s a big configuration step, and it’s clunky if we want to claim a magical decentralized experience.

I’m wondering how we can make it more seamless. If this is a complement to the web browser, but where you control the code and it’s integrated, it should feel like the creation of apps is easy and seamless.

I don’t have a solution yet here. Need answer on if we can use git generally. If so perhaps we can run git and just use hyperswarm for sync. Then if they care to later on they can push it to a repo.

The question is do we do revisions and git diffs as the primary thing we sync over hyperswarm? Seems like the only option.

natew commented 5 years ago

This is almost entirely done, minus publishing which can go into its own thing