Morphir is a multi-language system built on a data format that captures an application's domain model and business logic in a technology agnostic manner. This repo contains tools that allow you to write your business logic in Elm, parse it into Morphir IR and transpile it to other languages like Scala or visualize it to your business users using Elm.
We publish it both as an NPM and an Elm package:
- The NPM package contains the CLI for running the tools as part of your build.
- The Elm package supports multiple use-cases:
- It includes SDK functions that you can use while writing your business logic beyond the default
elm/coresupport. - It provides a type-safe API to work with the Morphir IR directly. You can use this to add your own logic builder, visualization or language transpiler.
- It also provides access to the frontend that parses the Elm source code and returns Morphir IR. You could use this to embed a business logic editor in your web UI.
- It includes SDK functions that you can use while writing your business logic beyond the default
The morphir-elm NPM package provides a CLI to run the tooling.
npm install -g morphir-elm
All the features can be accessed through sub-commands within the morphir-elm command:
morphir-elm [command]
Each command has different options which are detailed below:
This command reads Elm sources, translates to Morphir IR and outputs the IR into JSON.
morphir-elm make [options]
Important: The command requires a configuration file called morphir.json located in the project
root directory with the following structure:
{
"name": "My.Package",
"sourceDirectory": "src",
"exposedModules": [
"Foo",
"Bar"
]
}
- name - The name of the package. The package name should be a valid Elm module name and it should be used as a
module prefix in your Elm models. If your package name is
My.Packageall your module files should either be directly under that or in submodules. - sourceDirectory - The directory where your Elm sources are located.
- exposedModules - The list of modules in the public interface of the package. Module names should exclude the
common package prefix. In the above example
Foorefers to the Elm moduleMy.Package.Foo.
--project-dir <path>,-p- Root directory of the project where morphir.json is located.
- Defaults to current directory.
--output <path>,-o- Target location where the Morphir IR will be saved.
- Defaults to
morphir-ir.json.
This command reads the JSON produced by morphir-elm make and generates Scala sources into the specified folder:
morphir-elm gen [options]
--input <path>,-i- Source location where the Morphir IR will be loaded from.
- Defaults to
morphir-ir.json.
--output <path>,-o- Target location where the generated code will be saved.
- Defaults to
./dist.
The finos/morphir-elm package provides various tools to work with Morphir. It contains the following main components:
- The Morphir SDK which provides the base set of types and functions that Morphir tools support out-of-the-box. (the SDK is a superset elm/core with a few exceptions documented below)
- A type-safe API for the Morphir IR that allows you to create or inspect it.
elm install finos/morphir-elm
The goal of the Morphir.SDK module is to provide you the basic building blocks to build your domain model and
business logic. It also serves as a specification for backend developers that describes the minimum set of functionality
each backend implementation should support.
It is generally based on elm/core/1.0.5 and provides most of
the functionality provided there except for some modules that fall outside the scope of business knowledge modeling:
Debug, Platform, Process and Task.
Apart from the modules mentioned above you can use everything that's available in elm/core/1.0.5 without importing
the Morphir SDK. The Elm frontend will simply map those to the corresponding type/function names in the Morphir SDK.
The Morphir SDK also provides some features beyond elm/core/1.0.5. To use those features you have to import the
specific Morphir SDK module.
The Morphir.IR module defines a type-safe API to work with Morphir's intermediate representation. The module
structure follows the structure of the IR. Here's a list of concepts in a top-down approach:
- Distribution is the output
of
morphir-elm make. It represents a whole package with all of its dependencies. - Package represents a set of modules that are versioned together.
- Module is a container to group types and values.
- Types allow you to describe your domain model.
- Values allows you to describe your business logic.
- Names provide a naming
convention agnostic representation for all nodes that can be named: types, values, modules and packages. Names can be
composed into hierarchies:
- path is a list of names
- qualifield name is a module path with a local name
- fully-qualifield name is a package path with a qualified name
- AccessControlled is a utility to define visibility constraints for modules, types and values
- Fork it (https://github.com/finos/morphir-elm/fork)
- Create your feature branch (
git checkout -b feature/fooBar) - Read our contribution guidelines and Community Code of Conduct
- Commit your changes (
git commit -am 'Add some fooBar') - Push to the branch (
git push origin feature/fooBar) - Create a new Pull Request
NOTE: Commits and pull requests to FINOS repositories will only be accepted from those contributors with an active, executed Individual Contributor License Agreement (ICLA) with FINOS OR who are covered under an existing and active Corporate Contribution License Agreement (CCLA) executed with FINOS. Commits from individuals not covered under an ICLA or CCLA will be flagged and blocked by the FINOS Clabot tool. Please note that some CCLAs require individuals/employees to be explicitly named on the CCLA.
Need an ICLA? Unsure if you are covered under an existing CCLA? Email help@finos.org
Steps for publishing a new release
Copyright 2014 Morgan Stanley
Distributed under the Apache License, Version 2.0.
SPDX-License-Identifier: Apache-2.0