dolittle-obsolete / cli Goto Github PK

At first startup when doing dolittle or dolittle update, it pulls down the github repos multiple times and thus giving an error. Even though this is not really a problem because it actually pulls down all the files we should have a look at this.

Sitting in a folder for an application or within a folder in a bounded context - you should be able to do start dependencies.
Typically it should use docker to start a developer MongoDB for Event Stores and ReadModels.

Typically we need options to have the following structure:

{
   "options": [
      {
           "description":"the description of the option",
           "name": "the name of the option",
           "shortName": "the short name of the option"
      }
   ]
}

Example of this is
dolittle add command <name> --namespace <some.namespace>

The --namespace is the optional coming from the artifact-template, which is coming from the name property. The shortName of this could be -n:

dolittle add command <name> -n <some.namespace>

All options should just be added to the context object

┆Issue is synchronized with this Asana task

Repro on Mac:

• npm install -g @dolittle/cli
• dolittle

Fails with

info: Central Dolittle folder does not exist - creating it and setting up default configuration
fs.js:137
    throw new ERR_INVALID_CALLBACK();
    ^

TypeError [ERR_INVALID_CALLBACK]: Callback must be a function
    at makeCallback (fs.js:137:11)
    at Object.mkdir (fs.js:713:16)
    at ConfigManager.makeSureCentralFolderExists (/usr/local/lib/node_modules/@dolittle/cli/bin/configuration/ConfigManager.js:63:20)
    at new ConfigManager (/usr/local/lib/node_modules/@dolittle/cli/bin/configuration/ConfigManager.js:91:37)
    at new global (/usr/local/lib/node_modules/@dolittle/cli/bin/global.js:88:34)
    at Object.<anonymous> (/usr/local/lib/node_modules/@dolittle/cli/bin/global.js:278:19)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)

The set of tools that the CLI exposes are not CLI specific - in fact they can be used by a variety of tools, like plugins to code editors and in Dolittle Studio itself for instance. Instead of going through the CLI interaction layer, we could go through the API surface directly.

Separate into two different packages - the actual tool and the facade that gives you the CLI interface.

This needs to be looked at in conjunction with #58 - since extensibility is something we'd like for the underlying toolset as a whole as well.

The cli-tool should discover read models and list them up, asking whether the event processor should have dependency on read model repositories for that readmodel

During a run there are quite a few things that should be possible to capture as context. Properties that makes sense for the run.

For instance:

• Current working directory
• Selected language

The benefit of this is that everything could just be taking a dependency to the context and not having to figure out current working directory. It also improves the testability of the code.

There seems to be an issue with caching or suchlike in the build tool.

When manually editing the artifacts.json file, etc. (e.g. renaming the type or namespace) then the tool seems to remember the previous artifacts and generates the migration warning. Even deleting the file still generates the warning.

Restarting the IDE fixes the issue.

Kai has experienced this on Windows / Visual Studio.

We should change how the log statements gets presented. We don't want them prefixed with "loglevel". Instead we much rather want the different levels represented with colors - entire log statement in the given color.

Error: Red
Warning: Yellow
Info: Regular - default grey

┆Issue is synchronized with this Asana task

┆Issue is synchronized with this Asana task

It should be possible to just type:
$ brew install dolittle

┆Issue is synchronized with this Asana task

It should be possible to install it through Chocolatey:
c:\> choco install dolittle

┆Issue is synchronized with this Asana task

Concrete example; we want to be able to support Veracity and creating bounded contexts that are configured to work directly with Veracity. This should not be something developed directly in the tool itself - but rather be in its own repository and deployed on its own to NPM and discovered automatically by the tool.

Discovery mechanism needs to be figured out. But the idea is to have all capabilities available - meaning that the entrypoint of the tool will know about everything and have discovered all plugins - but not necessarily install it until its used.

This would make it very transparent for the developer.

┆Issue is synchronized with this Asana task

Sitting on top of boilerplates, we could have starter kits that will leverage potentially multiple boilerplates to create a setup in one go.

Starter kits can be anything from simple scaffolding to more complex scenarios with pre-baked application types one typically build. It could then hold multiple bounded contexts.

This should also set up for instance the Git repository and give a choice of pushing to a public or private repository on supported Source Control Providers (GitHub, VSTS ++).

It should also then ask to be connected to a Dolittle cluster - default being the official Dolittle Cloud and you need to be authenticated with it. It would then register the application in there and hook up build and deployment and everything.

The whole experience should be something like a minute effort till you have something running in the cloud (or private cluster).

┆Issue is synchronized with this Asana task

The goal is to put the application ID from the application.json file into the boundedContext.json file

• Command
• CommandHandler
• AggregateRoot
• Events
• EventProcessor
• ReadModel
• Query

Look into the possibility for expanding on things - for instance CommandHandlers and EventProcessors. You should be able to add a new "Handle/Process" method to an existing class

These are Filetemplates and comes from a boiler plate of type file templates.

For typically C# projects, we need to figure out the correct namespace. This is done by finding the nearest .csprojproject file up the hierarchy. From its name we and the subfolder(s) in which one is doing the creation of the artifact we know what the namespace would be.

Imagine having the current folder structure:

MyBoundedContext
    - Domain
       - SomeModule
          - SomeFeature

If sitting in the SomeFeaturefolder in CLI and the Domainfolder having a Domain.csprojfile - we take the name of the file and then append the SomeModuleand SomeFeature´ segments to the namespace yielding a namespace: Domain.SomeModule.SomeFeature`.

The templates files should have the following information:

{
   "name": "Name of the template",
   "description": "Description of the template",
   "language": "Programming language (csharp, javascript..)"
}

Ask the developer if the tool should add the command to the command handler.

┆Issue is synchronized with this Asana task

I think that the configuration file for the discovered boilerplates does not update correctly when the content in the .dolittle folder is updated

Leverage existing interaction layers and potentially introduce additional things that is needed for a composition that sits on top and could also provide an example of how the composition could be done with navigation and all.

An example of this is to use IFRAME for composing and having the navigation sitting around the contents IFRAME

┆Issue is synchronized with this Asana task

For example: for boilerplate.json for a C# artefact we could, for example, have a milestone field saying something like

"milestones": [
  "namespace": "*.csproj"  
]

child of #34

It seems there is a problem with Handlebars interpolation on Windows.
Its not replacing the thing it binds, it just prefixes it.

For example we can sit in Domain and do :
$ dolittle add command Feature.SubFeature.TheCommand
would automatically generate the feature folders
Domain
|-- Feature
|-- SubFeature
| TheCommand.something

We could have files that are specific for each of the choices made. This needs a bit of thinking.

Example of this could be for Web boilerplates:

Language:

• JavaScript
• TypeScript
• CoffeeScript

Framework:

• Aurelia
• React
• Angular
• ...

then for styles for instance:

• Dolittle Styles
• Material
• Bootstrap

┆Issue is synchronized with this Asana task

It should be possible on Ubuntu to do:
$ apt-get install dolittle

Or CentOS/RedHat Yum based:

$ yum install dolittle

┆Issue is synchronized with this Asana task

┆Issue is synchronized with this Asana task

Lets start by supporting Aurelia

Interaction where it finds all the commands in the folder you're adding CommandHandler and then you can select the commands the commandhandler will handle.

Same can be done with Events - although we need to either look at the dfirectory structure or the artifacts.json file or both

For example
$ dolittle add command TheCommand
should check whether or not current working directory is at the root of the bounded context (same directory as bounded-context.json). If it is, then the cli should try to find a folder named Domain and then generate the artifact in that folder instead of the 'cwd'.

If, however, you are trying to create a command in the Events folder, then you would be warned

For instance when creating a new bounded context, we want to run "npm install/yarn", dotnet restore and maybe even dotnet build.

┆Issue is synchronized with this Asana task

Instead of a .JS file - we should just have a standard JSON file.

In addition, take away the underscore prefix _template.js. File should just be called template.json.

We need to come up with an approach where we isolate language specific tooling.

For instance globals.js now have a method called getNearestCsprojFile(). This should not be there and we should come up with a pattern that enables us to have language specific information ready for the tasks needing without having to break the open/closed principle by having to add this code directly to a place like this.

Usual file new dir interface for windows does not work as expected for files that start with '.'.

mkdir works

When dolittle CLI is run the first time, run through and update

A portal is a collection of applications. When creating a portal one should get the choice of creating a compositional interaction layer for it. Much like with creating an application(#23).

A portal is typically that sits above applications and should probably be in its own repository completely independent from the applications. It could in fact also be a having a domain of sorts as well and you'd typically ask the developer for this.

Applications could be part of a portal - the portal needs to be formalized as a building block in Dolittle.

An example of a portal in context of Dolittle is the Dolittle Studio portal.

┆Issue is synchronized with this Asana task

When adding a bounded context, we should ask for adding an interaction layer - such as Web.
The interaction layer boilerplate chosen might have specific choices to be made, such as "Language: JavaScript / TypeScript", "Framework: Aurelia, Angular, React, Vue...", "Styles: Dolittle, Bootstrap, Material"

There are some dependencies on things though - so we need to collect as much as possible of information before we start the creation process.

For instance, the CSharp BoundedContext boilerplate will have an EntryPoint - an interaction layer on top, which sits in a different boilerplate will be applied in the same folder. Inside the C# entrypoint, for the .csprojfile - we have our postbuild step that can potentially generate proxies for JavaScript/TypeScript. This is optional and typically right now found in the boundedcontext.jsonfile inside the .dolittlefolder.

Once we have all the choices made, we put all the details into the context object and we can use for binding throughout. For instance we could then put in:

{
   "generateProxies": "true",
   "proxyPath": "../Web"
}

Depends on #10

In a multi-boilerplate scenario like this, we need to get the choices from the boilerplates we are bringing in. So the flow would be to look at the initial boilerplate one is building, then the choice of an interaction layer means that potentially a second boilerplate will be invoked and it can have choices defined in its JSON file. We bring it all together into the context before we instantiate the boilerplates.

┆Issue is synchronized with this Asana task