[RFC] Move logic into npm package/s and create template repository

[ResuBaka]

Summary

This would help to with updates in a project as the template with the modules and the core logic for the starting and loading would be two things.

Motivation

This would more line in how most other library and frameworks are doing it. So you only say yarn add @storefront/api and then you import from it like start and call it with its parameter.

This would help to have more clean packages that only to the things they need to and you can just import the features you need as a developer when we do it right with the splitting.

Guide-level explanation

Explain the proposal as if it was already included into the project and you were teaching it to another Vue Storefront developer. That generally means:

• Create a packages folder with core/...
• Examples on how other teams are doing it can be found in the nuxt repo, next repo
• You should not really think about core code and more about the code you write and that would happen when you don't see the core code directly as it is an node_modle

Reference-level explanation

This is the technical portion of the RFC. Explain the design in sufficient detail that:

• We need to have clear open APIs from the library that we export so that we don't kill any features that a user would think where public from the beginning
• We need to think on what we are allowing the user to over write Corner cases are dissected by
  • Graphql context
  • Logger
    There are maybe even more but that are the two things that are coming clearly to my mind.

We need to expose functions or have options in the functions with which you can overwrite these/change these.

Drawbacks

There would be more overhead on our side as there needs to be more thinking about if we allow the user to modify it or not. With the repo style that the user just uses the code directly he can modify every thing and only gets problems with updates.

Rationale and alternatives

• Why is this design the best in the space of possible designs?
• We would have a clear separation between the code from the developer that uses the code and the code of storefront-api
• What other designs have been considered and what is the rationale for not choosing them?
• The other designs would be the one that there is currently, which is not just that much as far as I know.
• What is the impact of not doing this?
• Updating the core code is going to be harder as every thing is public to the developer so sum changes where you would think that is an internal tool gets used by the developer that uses the library and then can't update as we have changed some internals that would not impact any public APIs.