Remove application specifics to external repository

[verdverm]

Proposal

Remove all application specifics from this repository and put them in their own.

The "Nothing" option: #654 ( my preference ) The "Submodule" option: #653

Benefits

• Separation of concerns. The repositories become independent in development and upgrading.
• This repository can define high-level concepts (like the cli command)
  • Applications / packages will have to define these internally
  • Applications / packages will require compliance with the concepts (or a subset)
  • this would also include complying with spinjs semantics to some extent
• Many versions and variations of applications can be used with this repository.
  • They become selectable starting points provided by the community
  • They could work very differently, or they could share modules to a great extent
  • There will likely be modules as a more granular component
  • These would have their own compliance / dependencies

So there becomes three levels of modularity:

1. The build system ( This repository )
2. Applications (external repositories "linked in")
   1. applications don't interact at the code level
   2. defines a root connector(s) (Features) with type safety
3. Modules (reusable application components)
   1. can be shared and have dependencies
   2. uses the connector concept to weave things together

How to Use

1. Users would clone this repository
2. The starting application base (package set + config) would be selected
   1. Probably a default one (depends on how the external application is integrated into this repository)
   2. Using git commands or just copying it in
   3. the cli could have a command added for this purpose
3. Start your development
4. Upgrades (still a question)
   1. Upgrading this repo around your application is simpler
   2. Upgrading the application base you selected is case-by-case
      1. (we may both be thinking about a better way forward here)
      2. https://github.com/sysgears/domain-schema
      3. I think we are really talking about regenerating boilerplate around user modified code

The setup instructions would be:

# Get the project
git clone https://github.com/sysgears/apollo-universal-starter-kit
cd apollo-universal-starter-kit

# Add a starting package set (application base)
git submodule init
git submodule add <repo-url> packages

# Setup the environment
yarn
yarn seed
yarn watch

How to Upgrade

1. Make a new repo for your existing application and packages code
2. Move your settings.js, config/ , packages/* to the root of the new repo
3. Adjust imports where settings.js is used
   1. This was the only change required on master branch
   2. Use: grep -Rn "settings" | grep import to find all the locations
4. Commit and push the new repository
5. Integrate the external application back into this repository
   1. Use a git submodule in AUSK which points to the application repository
   2. Copy the application repository into this repository

Point 5. has two options which depend on the user experience around maintaining updates to this repository around your application code. I will update this when I've created POC PRs for each.

For base packages provided by the community, update paths (and many other things) will likely be specific.

[larixer]

@verdverm I'm not sure why the ticket named like this and why this approach is needed. If everything from this repository will be moved out to the other repository, what will be left in this repository, nothing? What is the purpose of such move, why not left everything in this repository then?

I agree with the idea to have architecture for plugins/modules and move all the app specifics to plugins/modules (with every module having own repo), but just pulling out app specifics from one repo to another repo, without leaving meaningful glue here for installing these modules back, doesn't seem right to me

[verdverm]

As I look at what remains, I do see that there is not much left, but I still think there is too much coupling. A few things I've been thinking about in this context.

1. I think there are at least 3 "projects" in this repository
   1. The application code and files for configuring build
   2. Connectors (which has an external library now)
   3. The tools & cli / domain schema
2. I don't git clone yarn, lerna, apollo, spinjs etc to use or build an application
3. The update paths for users of starter kits / applications / build tools

How can I build and share an application based on AUSK, host it on GitHub, while still being able to pull updates in from AUSK?

[larixer]

@verdverm

How can I build and share an application based on AUSK, host it on GitHub, while still being able to pull updates in from AUSK?

Right now you fork this repository and develop your app on GitHub, then merge with upstream to merge changes from here and stay up to date.