Release setup

[mantoni]

In preparation for a 0.1.0 release of the rewrite this change

• configures the version lifecycle scripts
• adds meta data to package.json files
• adds LICENSE files to the npm modules

[mantoni]

I'm not 100% sure. We might find issues with real world testing that require breaking changes. I intend to make 0.x.x releases until we find that things are stable. This might happen pretty fast.

Then we need tests and documentation, as you mentioned, on the top level as well as individual sub projects. We might be able to get help with this if people can start playing with an early version.

An important feature (for me) is watch mode, like mocha --watch. I use this with my dev workflow very heavily, and it might require some changes.

I'm also thinking we could have a "no bundler" mode, where the built in server ships JS files, if the main file is using the native import to fetch them.

Once we have all this together, I'd rename the master branch to something like legacy or v8-maintenance, rename the rewrite branch to main and make it the default. We can cut a 1.0.0 before or after, that doesn't matter since the new modules are namespaced.

With git tags, we can't have tags for sub modules only. So I though we could publish new versions of one or more packages and then make a v9.x.x release tag with the changelog in the top level project.

What do you think?

[m90]

Then we need tests and documentation, as you mentioned, on the top level as well as individual sub projects. We might be able to get help with this if people can start playing with an early version.

Do you also plan on having documentation for how to add a custom driver? Would the code even allow for non-@mochify drivers right now?

An important feature (for me) is watch mode, like mocha --watch. I use this with my dev workflow very heavily, and it might require some changes.

Sounds like it makes sense to have this in a proper release (although I have to admit that I never use it).

I'm also thinking we could have a "no bundler" mode, where the built in server ships JS files, if the main file is using the native import to fetch them.

I don't know too much (actually too little) about ES modules, but how would that work? Would given source files be wrapped in a <script type="module"> and then concatenated or something?

Once we have all this together, I'd rename the master branch to something like legacy or v8-maintenance, rename the rewrite branch to main and make it the default. We can cut a 1.0.0 before or after, that doesn't matter since the new modules are namespaced.

Sounds good.

With git tags, we can't have tags for sub modules only. So I though we could publish new versions of one or more packages and then make a v9.x.x release tag with the changelog in the top level project.

I'm not entirely sure I understand this yet. Would that mean that @mochify/cli@1.2.3 is tagged v9.2.3? Or do I misunderstand something here? For the few namespaced packages I use on a daily basis (@aws-cdk and pouchdb-*) I always found it very convenient not having to figure out latest versions for each of them, but instead being able to use the same version for all of these.

[mantoni]

Do you also plan on having documentation for how to add a custom driver? Would the code even allow for non-@mochify drivers right now?

Yes, that would be nice. I created #248 for this.

I don't know too much (actually too little) about ES modules, but how would that work? Would given source files be wrapped in a Githubissues.

Githubissues is a development platform for aggregating issues.