We should simplify the implementation of a new framework in regi. As it is, there is too much code and configuration needed when there should be very little variance to most frameworks.

As Tony, I should be able to configure a project to output to a file

As Tony, I should be able specify pre-build and post-build scripts

Add CommandBase lifecycle to manage generic process binding and disposal

We should make a Python implementation of FrameworkService to expand the use-cases for regi.

As Tony, I should be able to use the regi init command to generate a regi.json file prepopulated using the project identifiers in the target folders.

As a user, I should be able to click on a URL in the terminal to easily navigate to my running applications.

Today:

Frontend is now listening on port 8080

Next:

Frontend is now listening on port 8080 (http://localhost:8080/)

I should be able to start all apps and services, and then restart one of those services from a separate commandline without disrupting the active regi process.

• This feature requires the implementation of a RegiContext for regi-to-regi communication and collaboration

As a user, I should be able to define my regi.yml file in a central repository, and let my microservices reference it externally. This will allow me to have a single source of truth, but multiple repositories that reference it.

As Tony, I want to be able to specify a regi configuration file so that I can execute regi from another directory or have multiple configuration files

We should add a desktop GUI for more goodness.

• Electron + Blazor?
• WPF?

We should make the following changes to the configuration property names to resolve confusion:

• required goes back to being optional
• options becomes arguments
• requires stays as requires

This should allow for better consistency in naming conventions and stops the double-dipping on property names.

As a dev, I should be able to define a project as a package so that regi can manage the versioning of these packages and provide a framework for consuming and deploying these packages independently.

The sources field throws an exception if the sources' key is lowercase.

As a user, I should be able to use YAML (i.e. regi.yml) to configure Regi.

As Tony, I should be able to set the log level for the console output to exclude/include warnings

We should make a Python implementation of FrameworkService to expand the use-cases for regi.

As Tony, I should be able to have multiple paths grouped under a single project.

We should create an abstraction layer for process management so that frameworks are more testable

Change configuration schema to support projects that are both an app and a test (typical in JS projects).

Proposed Schema:

{
  "projects": [
    {
      "name": "Frontend",
      "framework": "npm",
      "paths": ["./src/frontend"],
      "roles": ["app", "test"]
    },
    {
      "name": "Backend",
      "framework": "dotnet",
      "paths": ["./src/backend/Backend"],
      "roles": ["app"]
    },
    {
      "name": "Backend.Test",
      "framework": "dotnet",
      "paths": ["./src/backend/Backend.Test"],
      "roles": ["test"]
    },
    {
      "name": "E2E-Tests",
      "framework": "npm",
      "paths": ["./src/e2e-tests"],
      "roles": ["test"],
      "labels": ["integration"],
      "serial": true,
      "rawOutput": true,
      "requires": [
        "Frontend",
        "Backend"
      ],
      "environment": {
        "Test:Stubs:Foo": false
      }
    }
  ]
}

Changes:

• Add roles property as an array to specify the project's roles (i.e. "app", "test", etc.)
• Add labels property as an array to specify arbitrary labels for filtering (i.e. "integration")
• Remove type property as its function will be replaced by labels

As a user, I want to be able to discover a project with the init command that is both an app and a tests. The typical use case for this is a React project where the convention to have components files adjacent to their spec files (in the same project).

• This could be achieved by making every matched IIdentifier create and return a project. Then they would be used more specifically (ReactIdentifier, NodeIdentifier, JestIdentifier, etc.) without overlap
• Another option is to instead have a separate discovery class with Project and Roles properties

We should rename the optional property in the project schema to required with a default value of true because the distinction between optional and options is unnecessarily confusing.

We should separate the Regi project into Regi and Regi.CommandLine projects. This will allow for greater separation of concerns and a more flexible architecture.

Add a command (similar to flutter doctor that will diagnose any missing dependencies. Most of these will be optional but it will be helpful to visualize a complete configuration.

As Tony, I want my processes to execute async so that they do not clobber each other

Add documentation to the README and Wiki page that details the Regi configuration and all options.

Cleanup the the project structure to better comply with the single-responsibility principal

Example:

regi
-  docs
-  samples
-  src
   -  Regi.Configuration
   -  Regi.Commandline
   -  Regi.Core
   -  Regi.Frameworks.Abstractions
   -  Regi.Frameworks.Dotnet
   -  Regi.Frameworks.Node
-  test
   -  Regi.Configuration.Test
   -  Regi.Commandline.Test
   -  Regi.Core.Test
   -  Regi.Frameworks.Dotnet.Test
   -  Regi.Frameworks.Node.Test

Add an attribute (i.e. FrameworkCommandAttribute) to map a IFramework method to a FrameworkCommand. This is useful because it vastly reduces the configuration needed for each framework and allows the framework configuration/logic to be encapsulated within the implementation of FrameworkBase.

As a user, I would like to be able to pass a force option (-f or --force) to the init command to overwrite an existing config file.

• This could be a generic inheritance of RegiOptions since other (but not all) commands could use this

There should be an easy way to configure retry handlers for either a specific framework or globally. One example is that .NET Core will always return CSC : error CS2012: Cannot open ... if a file is locked while running/testing in parallel. Regi should be able to pause and retry when it encounters this error.

We should add an API for configuration externalization. This will benefit users because it enables frameworks/identifiers to be configured without a release of Regi.Core.

Potential implementations:

• Plugin model (most likely shipped as NuGet packages)
• Json configuration (in regi.json file)

All commands should have a relevant output summary

• Display execution time
• Display project count

Regi should have first-class support for Docker and Docker Compose. This should include the following features:

• Allow build/run/test of docker project types as well as a DockerIdentifier
• Allow the docker projects to be defined separately but executed with a Docker Compose aggregate
• An option to auto-generate Dockerfiles with a docker-compose.yml file on regi init?

As Tony, I want to be able to have one regi process listen to another regi process so that I can spy on the output of an application.

Refactor DirectoryUtility to be an injected dependency (rather than a static instance)

• This introduces test pollution

There should be a mechanism for building dependency trees so that regi can optimize the order in which projects are run/tested to reduce the number of retries/rebuilds needed.

We should make a Java implementation of FrameworkService to expand the use-cases for regi.