Separate Hoodie dependencies vs. the example app

[janl]

Currently. my-first-hoodie serves two purposes:

1. Pull together all Hoodie dependencies into a working whole system.
2. Provide a sample / demo app that uses that system.

These should be covered by two distinct modules.

A change in the sample / demo app should not cause a change in the dependency chain.

Conversely, it’d be great if people’s own apps could update to a new version of the Hoodie system by installing a newer version of module 1. At which point the sample app is completely ignored, because there already is an app.

Specifically, if a dev wants to update their app today, they have to look into the package.json of the latest version of my-first-hoodie and find the right packages that make up the Hoodie system, and then copy and paste the version numbers into their own app’s package.json.

Needless to say that this isn’t a very friendly operation. Given that we plan regular releases, upgrading an app should be super straightforward.

[janl]

cc @gr2m @svnlto @boennemann @zoepage @espy

[boennemann]

Here is my idea of how this could work:

I will consequently call "the thing that defines hoodie's versions and pulls everything together" hoodie-app. The demo app that is now inside my-first-hoodie is a hoodie-template.

So the hoodie-app, is nothing but a package.json with the appconfig, users and email-plugin and hoodie-server. We publish this using bundleDependencies and it's version number is also referred to as the hoodie build number, which might initially be the same as the marketing version.

Merging hoodie-app and a hoodie-template during new or update

So there is a step, that I'll call apply that installs a certain hoodie-app version onto an existing app or folder. There is no scenario where there is not an app or a folder yet, because otherwise the default hoodie-template gets copied there first.

1. install hoodie-app into ~/.hoodie/cache/x.y.z./
2. forEach dependency in hoodie-app we force copy it’s folder from hoodie cache to the existing folders node_modules folder
3. forEach dependency in hoodie-app we (over)write the dependency's version into the package.json
4. we write the version of hoodie-app to package.json hoodie.version
   (5. run npm shrinkwrap inside the app)
5. do nothing if the version in package.json hoodie.version is the one we’re installing, ‘-f’ option to skip this step

That’s the process of applying hoodie-app which is always the same for installs or updates.
(Nice side effect: Once you have applied one version of hoodie-app consequent applies are instant and offline capable.)

CLI

hoodie new <foldername (default: “my-first-hoodie”)> copies in the latest default hoodie-template and applies latest hoodie-app

hoodie new <foldername> -t <templatename> does the same with the specified template

hoodie update applies latest hoodie-app to cwd

hoodie update is also what you would do if you have an existing app, w/o hoodie

hoodie update x.y.z applies a specific version of hoodie-app

hoodie version not only prints the version of the cli, npm, node and the platform, but first and foremost the current version of hoodie-app. This could also verify if the version matches the dependencies defined in dependencies.

[boennemann]

@christophwitzko

[christophwitzko]

@boennemann nothing to add, sound pretty perfect for me. 👍