{"id":13640292,"url":"https://github.com/tindzk/seed","last_synced_at":"2025-05-12T04:30:41.215Z","repository":{"id":55842439,"uuid":"165534369","full_name":"tindzk/seed","owner":"tindzk","description":"Build tool for Scala projects","archived":false,"fork":false,"pushed_at":"2020-12-11T12:34:23.000Z","size":510,"stargazers_count":237,"open_issues_count":24,"forks_count":13,"subscribers_count":10,"default_branch":"master","last_synced_at":"2025-05-07T23:45:24.369Z","etag":null,"topics":["bloop","build-tool","cross-platform","idea","scala","scala-native","scalajs"],"latest_commit_sha":null,"homepage":"https://tindzk.github.io/seed/","language":"Scala","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/tindzk.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2019-01-13T17:34:14.000Z","updated_at":"2025-02-18T13:24:41.000Z","dependencies_parsed_at":"2022-08-15T07:50:10.975Z","dependency_job_id":null,"html_url":"https://github.com/tindzk/seed","commit_stats":null,"previous_names":[],"tags_count":8,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tindzk%2Fseed","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tindzk%2Fseed/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tindzk%2Fseed/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tindzk%2Fseed/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/tindzk","download_url":"https://codeload.github.com/tindzk/seed/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253675075,"owners_count":21945893,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["bloop","build-tool","cross-platform","idea","scala","scala-native","scalajs"],"created_at":"2024-08-02T01:01:09.682Z","updated_at":"2025-05-12T04:30:40.578Z","avatar_url":"https://github.com/tindzk.png","language":"Scala","funding_links":[],"categories":["Projects","Build Tools","构建工具"],"sub_categories":["微服务框架"],"readme":"# Seed\n[![Gitter](https://badges.gitter.im/seed-scala/community.svg)](https://gitter.im/seed-scala/community?utm_source=badge\u0026utm_medium=badge\u0026utm_campaign=pr-badge)\n[![Build Status](http://ci.sparse.tech/api/badges/tindzk/seed/status.svg)](http://ci.sparse.tech/tindzk/seed)\n[![](https://images.microbadger.com/badges/image/tindzk/seed.svg)](https://microbadger.com/images/tindzk/seed)\n[![](https://images.microbadger.com/badges/version/tindzk/seed.svg)](https://microbadger.com/images/tindzk/seed)\n[![](https://img.shields.io/docker/pulls/tindzk/seed.svg)](https://hub.docker.com/r/tindzk/seed)\n[![](https://img.shields.io/bintray/v/tindzk/maven/seed.svg)](https://bintray.com/tindzk/maven/seed/)\n[![](https://img.shields.io/github/tag/tindzk/seed.svg)](https://github.com/tindzk/seed/releases)\n\nSeed is a user-friendly, fast and flexible build tool for Scala projects. Builds are specified in a single [TOML](https://github.com/toml-lang/toml) file. Seed then handles the dependency resolution, and generates project configurations for the build server [Bloop](https://scalacenter.github.io/bloop/) and for the IDE [IntelliJ](https://www.jetbrains.com/idea/).\n\nSeed's primary focus is to provide a better user experience for defining and managing Scala builds. The TOML format was chosen as a lightweight alternative to a Scala-based DSL. The CLI is equipped with colour support and human-readable messages. A wizard allows to quickly create a new project configuration. There are also commands to package modules and to check for version updates.\n\nSeed was designed with large and modular projects in mind. Modules can reside in external directories and can be imported into the project scope. Thus, there is no need to publish any artefacts with `SNAPSHOT` versions. Furthermore, Seed can create an aggregate IDEA project that contains the project modules including the imported ones, such that there is no need to have multiple IDEA instances running.\n\nThe IDEA project is generated in one pass together with the Bloop project. Afterwards, the project can be opened in IDEA right away and is ready to work with. There is no waiting time since the dependencies have already been resolved by Seed and IDEA's build tool integration (sbt/Gradle/Maven) is being completely bypassed. This also allows to work around some bugs IDEA is riddled with.\n\nFurther speed improvements in the build pipeline are gained by using a build server for compilation. Seed delegates this responsibility to Bloop which has demonstrated a better performance over traditional Scala build tools. Only one Bloop server instance needs to be running in the background and the communication with the process takes place with one-shot CLI commands, so the memory consumption is considerably lower when working on multiple projects. Bloop also does not suffer from any out-of-memory problems as other build tools.\n\nAnother important feature is cross-platform support. Seed targets all Scala platforms (JVM, [JavaScript](https://www.scala-js.org/) and [LLVM](https://scala-native.readthedocs.io/en/latest/)) without the need for plug-ins. Cross-platform builds are first-order citizens which is reflected in the design of the configuration format. The same applies to alternative Scala compilers such as [Typelevel Scala](https://github.com/typelevel/scala).\n\nCustomisation is of importance which is why Seed has few defaults. You have to define a directory structure for your own needs. This is especially useful given Seed's cross-platform nature where you may want to share code between different platforms or use custom Scala versions for certain platforms.\n\nFinally, Seed can be used in CI setups. For this, a Docker image is provided which reduces the burden of setting up all system dependencies correctly that are needed for cross-platform builds.\n\n## Demo\nIn the following screencast, we create a minimal Typelevel Scala project for the JVM, JavaScript and native:\n\n[![asciicast](https://asciinema.org/a/221097.svg)](https://asciinema.org/a/221097)\n\n## Installation\nYou can either install Seed via Coursier or use a self-contained Docker image.\n\n### Coursier\nThe following prerequisites are needed:\n\n* **JVM**\n* **Coursier**: Coursier is a tool for fetching Maven and Ivy dependencies. It can also launch JAR entry points and create executable launchers.\n* **Bloop**: Bloop serves the function of compiling your projects. The latest version should work since Bloop configurations strive for backward compatibility. If you encounter any problems, you can always install the version Seed is targeting which is indicated in `seed version`.\n* **JavaScript:** [Node.js](https://nodejs.org/en/download/) needs to be installed if you want to run the project or its tests.\n* **LLVM:** For Scala Native projects to link, LLVM needs to be installed. Please refer to the [Scala Native documentation](http://www.scala-native.org/en/latest/user/setup.html) for more information.\n\nYou can create a launcher as follows:\n\n```shell\n# Use latest released version\nversion=$(curl https://api.github.com/repos/tindzk/seed/tags | jq -r '.[0].name')\n\n# Use pre-release version\nversion=$(curl https://api.bintray.com/packages/tindzk/maven/seed | jq -r '.latest_version')\n\ncoursier bootstrap \\\n    -r bintray:tindzk/maven \\\n    tindzk:seed_2.12:$version \\\n    -f -o seed\n```\n\nAlternatively, you can use Coursier's `launch` command to run Seed directly:\n\n```shell\ncoursier bootstrap \\\n    -r bintray:tindzk/maven \\\n    tindzk:seed_2.12:$version -- \\\n    help\n```\n\n### Docker\nA [self-contained Docker image](https://hub.docker.com/r/tindzk/seed) based on [Alpine Linux](https://alpinelinux.org/) is provided for all Seed versions. You can pull it from the public Docker Hub registry:\n\n```shell\n$ docker pull tindzk/seed:$version\n```\n\nIt contains a compatible Bloop version and all dependencies needed for cross-platform builds (JVM, Node, Clang/LLVM). You can use the image to build your projects. For example, the [toml-scala](https://github.com/sparsetech/toml-scala) project could be built as follows:\n\n```shell\n$ docker run -it tindzk/seed:$version /bin/sh\napk add git\ngit clone https://github.com/sparsetech/toml-scala.git\ncd toml-scala\nseed bloop\nbloop test toml-js toml-jvm\n```\n\nThis Docker image can be used in CI setups. [Here](https://github.com/sparsetech/toml-scala/blob/master/.drone.yml) is a [Drone CI](https://drone.io/) configuration for the same project.\n\n## Getting Started\nIn a previous section, you already saw Seed's project creation wizard (`init`). To illustrate the build format, we will now create a project manually. A complete Scala Native project can be defined in only five lines of TOML:\n\n```toml\n[module.demo.native]\nroot               = \".\"\nscalaVersion       = \"2.11.11\"\nscalaNativeVersion = \"0.3.7\"\nsources            = [\"src/\"]\n```\n\nThis build defines a Scala Native module with the name `demo`. Save the content to `build.toml`. Then, create the file `src/Main.scala` containing:\n\n```scala\nobject Main extends App {\n  println(\"Hello World\")\n}\n```\n\nNow, you can generate the Bloop and IDEA configurations as follows:\n\n```shell\n$ seed all\n```\n\nThis downloads all dependencies to `$HOME/.coursier` and creates projects for IDEA in `.idea/` and for Bloop in `.bloop/`. Instead of `all`, you could have also specified `bloop` or `idea` in order to only generate the respective configuration.\n\nThe final step is to compile and run your program:\n\n```shell\n$ seed run demo\n```\n\nThis compiles the module to `build/` and runs it.\n\n## Features\n* Succinct build specifications\n    * Written in TOML\n    * There is only one single configuration file\n    * Intuitive syntax without cryptic operators (`scalaDeps` and `javaDeps`, instead of `%%%`, `%%` and `%`)\n    * Ability to include other projects rather than publishing dependencies\n* Cross-platform modules are first-order citizens with support for all three Scala targets\n    * JVM\n    * JavaScript\n    * Native\n* Alternative compilers like Typelevel Scala are fully supported\n    * No manual patching of dependencies required\n* Fast dependency resolution via [Coursier](https://github.com/coursier/coursier)\n    * Once a configuration has been generated, the dependencies do not need to be resolved a second time\n    * The user does not need an Internet connection if the dependencies are already locally available\n* Shorter compilation times\n    * Leverages external Bloop build server that is optimised for compilation speed\n    * Optional compilation to tmpfs for in-memory builds\n* IDE project generation for IntelliJ IDEA\n    * Avoids overhead of sbt/Gradle/Maven projects\n    * Better integration of cross-platform projects\n* Custom build targets to run external commands or main classes\n    * Generate code\n    * Build non-Scala artefacts\n* Organised file structure\n    * There is only one build folder per project (as opposed to `target` folders for every module in sbt)\n    * Custom project source structures are easily configured, e.g. `src/` and `test/` instead of the more lengthy `src/{main,test}/scala/`\n* Can be used alongside other build tools (e.g. sbt)\n    * Default paths were chosen not to conflict in any way\n* Can be used in CIs like [Drone](https://drone.io/) using pre-built Docker image\n* UX\n    * True colour output\n    * User-friendly messages\n    * Unicode characters\n    * Progress bars\n* Project creation wizard\n* Generate module documentation\n* Publish artefacts to Bintray\n    * Read version from Git repository\n* Package modules\n    * Copy over dependencies\n* Server mode\n    * Expose a WebSocket server\n    * Clients can trigger compilation and linking of modules\n    * Clients can subscribe to build events\n* Check for dependency updates\n    * Choose library versions separately for each platform to avoid incompatibilities\n* Simple design\n    * No distinction between managed/unmanaged/generated sources\n    * No ability to define tasks\n    * No plug-in infrastructure\n    * Tiny code base\n\n## Build Configuration\nThe [TOML file format](https://github.com/toml-lang/toml) is used for all configuration files. A language extension was enabled to [allow line breaks in inline tables](https://github.com/toml-lang/toml/issues/516).\n\nThe default build file is named `build.toml`. You can specify a custom path with the `--build` parameter. A build file corresponds to a *project* which can contain multiple *modules*.\n\nThis section explains the components of build configurations and provides examples you can use in your own build files.\n\n### Project\nProject-wide settings are defined in the optional `[project]` section and are inherited by all modules defined in the same file:\n\n```toml\n[project]\nscalaVersion       = \"2.12.4-bin-typelevel-4\"       # Mandatory; Scala version to be used by all modules\nscalaJsVersion     = \"0.6.23\"                       # Optional; only needed for JavaScript compilation\nscalaNativeVersion = \"0.3.7\"                        # Optional; only needed for native compilation\nscalaOrganisation  = \"org.typelevel\"                # Optional; defaults to `org.scala-lang`\nscalaOptions       = [\"-Yliteral-types\"]            # Optional; empty by default\ntestFrameworks     = [\"minitest.runner.Framework\"]  # Entry points for test frameworks\n                                                    # Explained in section \"Test module\" below\n```\n\nAll of these settings can be overridden by modules.\n\n### Module\nA module groups source paths and related settings into a compilation unit. The basic syntax of a module as follows:\n\n```toml\n[module.myModule]\ntargets = [\"jvm\", \"js\"]\nroot    = \"src\"\nsources = [\"src\"]\n```\n\nThis defines a *cross-compiled module* with a JVM and JavaScript target. For every module, a list of source paths has to be specified. The source paths can be files and directories. You also have to define a root path (`root` setting) if you would like to generate an IntelliJ project.\n\nSince Seed is platform-agnostic, every module needs to specify a target platform. This is either achieved with the `targets` setting or by including the platform in the module header definition:\n\n```toml\n[module.myModule2.jvm]\nsources = [\"src\"]\n\n[module.myModule2.js]\nsources = [\"src\"]\n```\n\nThese two definitions are called *platform-specific modules*. Both modules are equivalent to `myModule`.\n\nA module can have an optional test module:\n\n```toml\n# Cross-compiled\n# Inherits all settings from base module (e.g. root, targets and sources)\n[module.myModule.test]\nsources = [\"test\"]\n\n# Platform-specific\n[module.myModule2.test.jvm]\nsources = [\"test\"]\n```\n\nFor any module, the following options are available:\n\n```toml\n[module.myModule]\nscalaVersion       = \"\"  # Must be set on every module\nscalaJsVersion     = \"\"  # Only used if module has JavaScript target\nscalaNativeVersion = \"\"  # Only used if module has native target\nscalaOptions       = []  # Empty by default\nscalaOrganisation  = \"\"  # Defaults to `org.scala-lang`\ntestFrameworks     = []  # Only used by test module\nroot               = \"\"  # Module root path for IntelliJ\nsources            = []  # List of source directories and files\nscalaDeps          = []  # Module-specific Scala dependencies\ncompilerDeps       = []  # Compiler plug-ins (specified in the same format as scalaDeps)\nmoduleDeps         = []  # Module dependencies\nmainClass          = \"\"  # Optional entry point; needed for running/packaging module\ntargets            = []  # Platform targets\n```\n\nUnless overridden in the module, the settings are inherited from the `[project]` section.\n\n### Cross-platform module\nA cross-platform module is a module that has one or multiple targets. The target platforms your code can be compiled to is only limited by the language features and libraries your code makes use of. Not all libraries and Scala features are available during JavaScript and native compilation. For most code, cross-platform support will be as simple as adding another target. For other projects, you will have to factor out platform-specific logic into a submodule (see next section).\n\n```toml\n[module.myModule]\nroot    = \"jvm\"\nsources = [\"src\"]\ntargets = [\"js\"]\n```\n\nWhen you generate the Bloop configuration with `seed bloop`, this will create `myModule` as there is only one platform. You can compile it using `bloop compile myModule`. We can specify multiple targets:\n\n```toml\n[module.myModule]\n# ...\ntargets = [\"js\", \"jvm\", \"native\"]\n```\n\nThis is equivalent to defining a separate module for each platform.\n\nIn the Bloop configuration, this corresponds to an aggregate module `myModule` as well as three modules with the platform appended to each. You can compile them with `bloop compile myModule-\u003ctarget\u003e` whereas `\u003ctarget\u003e` is one of `js`, `jvm` and `native`.\n\nReturning to our initial example from the \"Getting Started\" section, we can change it as follows to make it compile for JVM and native:\n\n```toml\n# Instead of `[module.demo.native]`\n[module.demo]\nroot               = \".\"\nscalaVersion       = \"2.11.11\"\nscalaNativeVersion = \"0.3.7\"\nsources            = [\"src/\"]\ntargets            = [\"jvm\", \"native\"]  # This line was added\n```\n\n### Platform-specific module\nA platform-specific module inherits all settings from its parent and extends them:\n\n```toml\n[module.myModule]\nroot    = \"shared\"\nsources = [\"shared/src\"]\ntargets = [\"jvm\", \"js\"]\n\n[module.myModule.jvm]\nroot      = \"jvm\"\nsources   = [\"jvm/src\"]\nresources = [\"jvm/res\"]\n\n[module.myModule.js]\nroot      = \"js\"\nsources   = [\"js/src\"]\nscalaDeps = [[\"org.scala-js\", \"scalajs-dom\", \"0.9.5\"]]\n```\n\nHere, we use a cross-platform module in conjunction with two platform-specific modules. This is useful if you have code that should be shared across multiple platforms, and if certain platforms have additional functionality or provide a specific implementation for a feature.\n\nIn the base module, the source path is `src` which we extend in the JVM- and JavaScript-specific modules with platform-specific sources, i.e. `jvm/src` and `js/src`. For example, the command `bloop compile myProject-jvm` would compile all sources from the base module and additionally include files from `jvm/src`.\n\nIt is possible to set a custom Scala version for modules. This is needed when a platform does not support the latest Scala version yet, as is the case with Scala Native. You can globally set the version to 2.12 which will be then used by JavaScript and JVM, but the Scala Native module will use 2.11:\n\n```toml\n[project]\nscalaVersion = \"2.12.8\"\n\n[module.myModule.native]\nscalaVersion = \"2.11.11\"\n```\n\n#### JVM\nThe available JVM options are:\n\n```toml\n[module.myModule.jvm]\njavaDeps  = []  # Java dependencies\nresources = []  # List of resource paths\n```\n\n#### JavaScript\nThe available JavaScript options are:\n\n```toml\n[module.myModule.js]\njsdom          = false  # Import the jsdom library in the generated.\n                        # JavaScript file. Must be installed via\n                        # yarn/npm. Useful for test cases that rely\n                        # on DOM operations.\nemitSourceMaps = true   # Emit source maps\nmoduleKind     = \"default\"  # Options: default, commonjs\noutput         = \"myModule.js\"  # Path to generated file\n                                # Default: \u003cmodule name\u003e.js\n```\n\n#### Native\nThe available native options are:\n\n```toml\n[module.myModule.native]\ngc              = \"immix\"  # Garbage collector. Options: none, immix or boehm\ntargetTriple    = \"\"       # See https://clang.llvm.org/docs/CrossCompilation.html#target-triple\nclang           = \"/usr/bin/clang\"\nclangpp         = \"/usr/bin/clang++\"\ncompilerOptions = []       # Options passed to Clang during compilation\nlinkerOptions   = []       # Options passed to Clang during linking\nlinkStubs       = false    # Link or ignore @stub definitions\noutput          = \"myModule.run\"  # Path to generated file\n                                  # Default: \u003cmodule name\u003e.js\n```\n\n### Dependencies\nIn all modules, you can specify `scalaDeps` which will be resolved to the corresponding artefacts for each target platform:\n\n```toml\n[module.myModule]\nroot      = \"shared\"\nsources   = [\"shared/src\"]\ntargets   = [\"js\", \"jvm\"]\nscalaDeps = [\n  [\"io.circe\", \"circe-parser\", \"0.9.3\"]\n]\n```\n\nThis dependency can be only resolved if `circe-parser` is available for Scala.js and JVM. If a dependency is not available for a platform, you can move it to a platform-specific module:\n\n```toml\n[module.myModule.jvm]\nscalaDeps = [\n  [\"org.scalaj\", \"scalaj-http\", \"2.4.1\"]\n]\n```\n\nOn `scalaDeps`, you can specify a fourth parameter for the version tag. The version tag is the actual difference between a Java and Scala dependency.\n\nThe Scala naming conventions stipulate that a suffix be added to the artefact name. Thus, `scalaj-http` becomes [`scalaj-http_2.12`](http://central.maven.org/maven2/org/scalaj/scalaj-http_2.12/).\n\nThe previous example could be rewritten as:\n\n```toml\nscalaDeps = [\n  [\"org.scalaj\", \"scalaj-http\", \"2.4.1\", \"platformBinary\"]\n]\n```\n\nThe default is `platformBinary` which will suit most libraries. However, some libraries target a specific compiler version or share one artefact with all platforms.\n\nThe available options are:\n\n* `binary`: Binary Scala version (e.g. 2.12). This behaves like `full` if the Scala version is a pre-release (e.g. `2.12.8-M3`)\n* `full`: Full Scala version (e.g. `2.11.11`)\n* `platformBinary`: Platform name including the binary Scala version (`native0.3_2.11`)\n\n`scalaDeps` only works with Scala artefacts. For all other artefacts, you can use `javaDeps`:\n\n```toml\n[module.myModule.jvm]\njavaDeps = [\n  [\"com.zaxxer\"        , \"nuprocess\"       , \"1.2.3\"],\n  [\"org.apache.commons\", \"commons-compress\", \"1.17\" ]\n]\n```\n\nNote that the `javaDeps` setting is only available on JVM projects.\n\n### Test module\nTo run tests on a certain module, you can add a test module for it:\n\n```toml\n[module.myModule.test]\nsources   = [\"shared/test\"]\ntargets   = [\"js\", \"jvm\"]\nscalaDeps = [\n  [\"org.scalatest\", \"scalatest\", \"3.0.5\"]\n]\n```\n\nThis module is cross-platform and the tests are shared by the two targets.\n\nYou can also define a platform-specific test module:\n\n```toml\n[module.myModule.test.js]\nsources = [\"js/test\"]\n```\n\nIf you add a test framework, make sure that `testFrameworks` in `project` contains its qualified class name. Common test frameworks are:\n\n* **ScalaTest:** `org.scalatest.tools.Framework`\n* **ScalaCheck:** `org.scalacheck.ScalaCheckFramework`\n* **MiniTest:** `minitest.runner.Framework`\n* **µTest:** `utest.runner.Framework`\n* **MUnit:** `munit.Framework`\n\nIn Bloop, you can run the test suites as follows: `bloop test myModule` which is short for `bloop test myModule-test`. The latter depends on `myModule-js-test` and `myModule-jvm-test`.\n\nTest modules inherit settings from their parents. Therefore, `root` does not need to be set again. IntelliJ will aggregate sources and tests under the same root.\n\n### Module dependencies\nModules can depend on other modules. An example is a full-stack web application with a shared cross-compiled core:\n\n```toml\n[module.core]\nsources = [\"core/src\"]\ntargets = [\"js\", \"jvm\"]\n\n[module.webapp.js]\nmoduleDeps = [\"core\"]\nsources    = [\"frontend/src\"]\n\n[module.server.jvm]\nmoduleDeps = [\"core\"]\nsources    = [\"server/src\"]\n```\n\nSetting `moduleDeps` to `core`, gives `webapp` and `server` access to its compiled sources.\n\n`moduleDeps` can refer to any modules available in the scope as long as the target platforms match.\n\n`bloop compile webapp` triggers the compilation of `core-js` whereas `bloop compile server` would compile `core-jvm`.\n\n### Custom build targets\nYou can specify custom targets on a module, for example to build artefacts (HTML, CSS) or to generate code that dependent modules will compile. A target can run shell commands and main classes.\n\nAs an example, we could generate CSS artefacts from SCSS using [Gulp](https://gulpjs.com/). The corresponding entry for spawning the Gulp process would look as follows:\n\n```toml\n[module.template.target.scss]\nroot    = \"scss\"\ncommand = \"yarn run gulp\"\n```\n\nSince we specified `root`, it will also generate a IDEA module named `template-scss`. We could build the target explicitly with `seed build template:scss`, or simply `seed build template`. If the module `template` has regular Scala targets, the latter would compile their sources too along with all custom targets.\n\nNote that you will have to either use `seed build` or `seed link` since Bloop commands are not aware of your build targets.\n\nWhen you depend on a module in `moduleDeps`, all of its targets are inherited. Any module that transitively depends on `template`, will run the target command when building.\n\nThe current working directory is the path to the module's build file. The environment variable `BUILD_PATH` will point to the build path of the root project. You can access it in the command itself:\n\n```toml\n[module.template.target.fonts]\nroot    = \"fonts\"\ncommand = \"cp -Rv fonts $BUILD_PATH\"\n```\n\nBy default, the process execution is asynchronous. If you need the process to complete first before continuing with the compilation process, you can override the `await` setting which is set to `false` by default:\n\n```toml\n[module.template.target.gen-scala]\nawait   = true\ncommand = \"...\"\n```\n\nIf your command has support for a watch mode, you can additionally specify a `watchCommand`:\n\n```toml\n[module.template.target.scss]\nroot         = \"scss\"\ncommand      = \"yarn run gulp\"\nwatchCommand = \"yarn run gulp default watch\"\n```\n\nThe watch command is used when the user specifies `--watch`:\n\n* `seed build template:scss --watch`\n* `seed link template:scss --watch`\n\nIf `--watch` is not provided, Seed will spawn the `command` instead. Note that the `watchCommand` ignores `await` and is always run asynchronously.\n\nBesides spawning commands, you can run any main class defined in the project. For example, to generate a JavaScript file, you could define:\n\n```toml\n[module.layouts.target.js-bundle]\nroot = \"layouts\"\n\nclass = { module = \"keyboard:jvm\", main = \"keyboard.Bundle\" }\n\n# or shorter:\n# class = [\"keyboard:jvm\", \"keyboard.Bundle\"]\n```\n\nIn addition to `BUILD_PATH`, we also set the environment variable `MODULE_PATH` when running classes. The module path is the root path of the Seed project which contains the referenced module. This environment variable is not set for commands since their current working directory will point to the module path.\n\nIt is possible for multiple modules to share a code generator. To access the source paths of all modules that depend on a generator, access the environment variable `MODULE_SOURCE_PATHS`. Its value uses the system path separator character (`java.io.File.pathSeparatorChar`).\n\nFor examples of using code generation, please refer to these links:\n\n* [Class target](test/custom-class-target/)\n* [Class target shared by multiple modules](test/custom-class-target-shared/)\n* [Command target](test/custom-command-target/)\n\n### Compiler plug-ins\nScala plug-ins can be included with the `compilerDeps` setting. It behaves similar to `scalaDeps`, but adds the `-Xplugin` parameter to the Scala compiler. `compilerDeps` is available on the project as well as module level:\n\n```toml\n[project]\ncompilerDeps = [\n  [\"org.scalameta\", \"semanticdb-scalac\", \"4.2.0\", \"full\"]\n]\n\n[module.macros.js]\ncompilerDeps = [\n  [\"org.scalamacros\", \"paradise\", \"2.1.1\", \"full\"]\n]\n```\n\nNote that project-level plug-ins are inherited by all modules defined in the project file. When module `a` depends on module `b` which defines compiler plug-ins, these are inherited by `a`. Thus, in order to avoid duplication, shared compiler dependencies can be defined on base projects and modules.\n\nIn the example above, `module.macros.js` inherits the SemanticDB plug-in from the project and adds a separate dependency for the Macro Paradise plug-in.\n\nFor a complete cross-compiled Macro Paradise example, please refer to [this project](test/example-paradise/).\n\n### Project dependencies\nExternal builds can be imported into the scope by using the `import` setting at the root level. It can point to a build file, or its parent directory in which case it will attempt to load `\u003cpath\u003e/build.toml`. From the imported file, Seed will only make its modules accessible. Other project-level settings are being ignored. Multiple projects can be imported as `import` is a list.\n\nSince all modules are imported into the scope, they can be depended on by local modules:\n\n```toml\nimport = [\"foo\"]  # Imports `foo/build.toml`\n\n[project]\n# ...\n\n[module.bar.jvm]\nmoduleDeps = [\"fooCore\"]  # Assuming that the foo project contains a module named fooCore\n```\n\nAs with regular modules, for each of the imported ones a Bloop file is created. Then, as part of the current build, Bloop will resolve the external project dependencies and compile their sources locally. This is to avoid any binary incompatibilities that could arise if the referenced project used different platform versions or compiler settings.\n\nNote that project dependencies are inherited transitively.\n\n### Paths\n#### Directory structure\nSeed does not impose any default file structure. Other build tools use the default `src/main/scala` which is unnecessarily verbose and insufficient as soon as cross-platform modules are involved. Therefore, it is entirely up to the user to set a custom structure for the project in Seed.\n\nFor projects with only one module, Scala files could be stored in `src/` and tests in `test/`. This change would look as follows:\n\n```toml\n[module.app]\nroot    = \".\"  # This allows IntelliJ to aggregate the source and test module\nsources = [\"src\"]\n\n[module.app.test]\nsources = [\"test\"]\n```\n\nIf your project relies on generated Scala/Java files, you can simply add their paths to the `sources` list.\n\n### Resolvers\nThe default resolvers are as following:\n\n```toml\n[resolvers]\nmaven = [\"https://repo1.maven.org/maven2\"]\nivy   = []\n```\n\nTo add an Ivy resolver, the URL must be wrapped in a list:\n\n```toml\n[resolvers]\nivy = [\n  [\"https://repo.typesafe.com/typesafe/ivy-releases\"]\n]\n```\n\nThe reason for this is that the Ivy pattern may be omitted. It is short for:\n\n```toml\n[resolvers]\nivy = [\n  {\n    url     = \"https://repo.typesafe.com/typesafe/ivy-releases\",\n    pattern = \"[organisation]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]\"\n  }\n]\n```\n\n### Package\nWhen publishing artefacts, a [Maven POM](http://maven.apache.org/pom.html) file is created. To configure its contents, define a `package` section:\n\n```toml\n[package]\n# Project name (`name` field)\n# name = \"example\"\nname = \"\"\n\n# Package organisation (`groupId` field)\n# organisation = \"com.smith\"\norganisation = \"\"\n\n# List of developers (ID, name, e-mail)\n# developers = [{ id = \"joesmith\", name = \"Joe Smith\", email = \"joe@smith.com\" }]\n# developers = [[\"joesmith\", \"Joe Smith\", \"joe@smith.com\"]]\ndevelopers = []\n\n# Project URL\nurl = \"\"\n\n# List of project licences\n# Available values:\n# gpl:2.0, gpl:3.0, lgpl:2.1, lgpl:3.0, cddl:1.0, cddl+gpl, apache:2.0, bsd:2,\n# bsd:3, mit, epl:1.0, ecl:1.0, mpl:2.0\n# licences = [\"apache:2.0\"]\nlicences = []\n\n# Source code information\n# `developerConnection` is optional and if omitted, has the same value as `connection`\n#scm = {\n#  url = \"https://github.com/joesmith/example\",\n#  connection = \"scm:git:git@github.com:joesmith/joesmith.git\",\n#  developerConnection = \"scm:git:git@github.com:joesmith/joesmith.git\"\n#}\nscm = { url = \"\", connection = \"\", developerConnection = \"\" }\n\n# Publish sources\n# Alternatively, use --skip-sources to override this setting\nsources = true\n\n# Generate and publish documentation\n# Alternatively, use --skip-docs to override this setting\ndocs = true\n```\n\n### Sample configurations\nYou can take some inspiration from the following projects:\n\n* [toml-scala](https://github.com/sparsetech/toml-scala/blob/master/build212.toml) (CI [configuration](https://github.com/sparsetech/toml-scala/blob/master/.drone.yml), [demo](http://ci.sparse.tech/sparsetech/toml-scala))\n\nIf you have any Seed configurations you deem worth sharing, please feel free to add them to this list!\n\n## Seed configuration\nSeed has a global configuration file which is stored in `~/.config/seed.toml`.\n\n### tmpfs\nBy default, all modules are compiled to the `build/` directory within the project folder.\n\nOn Linux, you can compile your entire project in memory to improve speed and reduce disk wear out. This feature was modelled after [sbt-tmpfs](https://github.com/cuzfrog/sbt-tmpfs).\n\nYou can enable it for your builds with the `--tmpfs` flag, or use a global setting:\n\n```toml\n[build]\ntmpfs = true\n```\n\nThis setting is also honoured by the generated IntelliJ project.\n\n### Artefact resolution\nThe following global settings are available for artefact resolution:\n\n```toml\n[resolution]\n# Do not show the downloaded artefacts\n# Useful to shorten logs in CI pipelines\nsilent = false\n\n# Ivy path\n# Can be also set with --ivy-path\nivyPath = \"/home/user/.ivy2/local\"\n\n# Artefact cache path\n# Can be also set with --cache-path\ncachePath = \"/home/user/.cache/coursier/v1\"\n\n# Fetch JavaDoc and source artefacts for all library dependencies. Then,\n# populate the resolution section in Bloop. This setting is only needed if you\n# use Bloop with IDEs, e.g. Metals or IntelliJ.\n# See also https://scalacenter.github.io/bloop/docs/build-tools/sbt#download-dependencies-sources\n#\n# If you generate an IDEA project, these artefacts will always be downloaded.\noptionalArtefacts = false\n```\n\nThe default values are indicated.\n\n### CLI settings\nIn the `cli` section, you can find output-related configuration settings:\n\n```toml\n[cli]\n# Log level\n# Possible values: debug, warn, info, error, silent\nlevel = \"debug\"\n\n# Use Unicode characters to indicate log levels\nunicode = true\n\n# Show progress bars when compiling modules\nprogress = true\n```\n\nThe default values are indicated.\n\n### Publishing settings\n```toml\n# Bintray repository credentials\n[repository.bintray]\nuser   = \"\"\napiKey = \"\"\n```\n\nIf you maintain your configuration files in a public Git repository, it is advisable to move the Bintray section to a separate untracked file (e.g. `seed-credentials.toml`) and import it from the main configuration:\n\n```toml\nimport = [\"seed-credentials.toml\"]\n```\n\n## Git\n### .gitignore\nFor a Seed project, `.gitignore` only needs to contain these four directories:\n\n```\n/.idea/\n/.bloop/\n/.metals/\n\n/build/\n```\n\n### Dependencies\nIf another build uses Seed and Git for versioning, there is no need for publishing `SNAPSHOT` dependencies. Instead, Git modules would be a simpler solution. All dependencies could be fetched in a subfolder of the current project.\n\n```shell\n$ cat .gitmodules\n[submodule \"otherProject\"]\n  path = otherProject\n  url = https://github.com/org/otherProject.git\n```\n\nThen, use the following command to fetch the dependencies:\n\n```shell\n$ git submodule update --init --recursive\n```\n\nFinally, this project can be embedded using the `include` setting in Seed.\n\nThis approach is easier to manage in CI setups as Git modules track a specific commit, whereby the builds are reproducible. Git modules also work with transitive dependencies (`--recursive`).\n\n## Usage\nSeed delegates the compilation phase to an external tool. Bloop is an intuitive build server that runs on the same machine as a background service. Its architectural design allows for shorter compilation cycles and lower overall memory consumption when working on multiple projects at the same time.\n\n### Building, linking and running\nAfter having created a Bloop project with `seed bloop`, you can compile, link and run modules directly from Seed:\n* `seed build \u003cmodule\u003e`  This will compile all platform modules\n* `seed link \u003cmodule\u003e`   This will link all platform modules which support linking (JavaScript and Native)\n* `seed run \u003cmodule\u003e`    This will run a compatible platform module (JVM, JavaScript and Native)\n\nYou can select a specific platform:\n* `seed build \u003cmodule\u003e:js`  This will compile only the JavaScript module\n* `seed link \u003cmodule\u003e:js`   This will link only the JavaScript module\n* `seed run \u003cmodule\u003e:js`    This will run only the JavaScript module\n\nIf you defined a [custom build target](#custom-build-targets), you can use the same syntax to build it:\n* `seed build \u003cmodule\u003e:\u003ctarget\u003e`\n\nIf you run Seed in [server mode](#server-mode), you can connect to your remote Seed instance using the `--connect` parameter:\n* `seed build --connect \u003cmodule\u003e` Trigger compilation on remote Seed instance\n* `seed link --connect \u003cmodule\u003e`  Trigger linking on remote Seed instance\n* `seed run --connect \u003cmodule\u003e`   Trigger running on remote Seed instance\n\nAlso, run `seed --help` to acquaint yourself with all the available commands.\n\nAs Seed creates a regular Bloop project, the official Bloop CLI can be used as well:\n\n```shell\nbloop compile \u003cmodule\u003e      # Compile module\nbloop run \u003cmodule\u003e          # Run main class\nbloop run \u003cmodule\u003e --watch  # Watch for source changes, recompile and restart\nbloop test \u003cmodule\u003e         # Run test cases\n```\n\nFor more detailed information, please refer to the official [Bloop user guide](https://scalacenter.github.io/bloop/).\n\n### Server mode\nYou can run Seed in server mode. By default, it will listen to JSON commands on the WebSocket server `localhost:8275`. It supports several commands:\n\n- Linking modules\n- Publishing build status events\n\nYou could use the server as a message bus. You can trigger a link from the IDE or the command line. At the same time, there can be multiple event listeners subscribing to build status events. This is useful if you develop a Scala.js application and want to reload the website in the browser after each build.\n\nThis can be achieved in three steps:\n\n1. Run `seed server` in the background\n2. If you use IntelliJ, configure \"Run/Debug Configuration\":\n  - Create template from \"Bash\"\n    - Script: `/home/user/bin/seed`\n    - Interpreter path: `/bin/sh`\n    - Program arguments: `link --connect \u003cmodule\u003e`\n    - Working directory: `\u003cproject path\u003e`\n3. In your Scala.js application, run this code upon start-up:\n\n```scala\n/** Subscribe to build notifications. Whenever any module was linked, evaluate\n  * `onLinked`.\n  */\ndef watch(onLinked: =\u003e Unit): Unit = {\n  val client = new WebSocket(\"ws://localhost:8275\")\n  client.onopen = _ =\u003e\n    client.send(JSON.stringify(new js.Object { val command = \"buildEvents\" }))\n  client.onmessage = message =\u003e {\n    val event =\n      JSON.parse(message.data.asInstanceOf[String]).event.asInstanceOf[String]\n    if (event == \"linked\") onLinked\n  }\n}\n\nwatch(dom.window.location.reload())\n```\n\nPress Shift-F10 in IntelliJ to trigger the build. Bloop's output is forwarded and shown in the same window. Once the linking is done, the page in the browser will reload.\n\n## IntelliJ IDEA\nSeed has the ability to generate IDEA configurations. It copes better with cross-platform projects than IDEA's sbt support. It has the additional benefit of being faster and having a lower memory consumption since no sbt instance needs to be spawned.\n\nIf you are replacing an existing sbt project or creating a new IDEA project with Seed, make sure IDEA is not started and the project loaded. Otherwise, refreshing IDEA projects is as simple as running `seed idea`. IntelliJ will pick up the changes immediately and does not need to be restarted.\n\nWhen you generate a configuration for IDEA, Seed will also fetch Javadoc and source files as part of the dependency resolution.\n\nA common problem with imported cross-platform projects in IntelliJ is that tests cannot be run and code highlighting for shared modules does not work. Seed works around these bugs by setting up the dependencies correctly (from `\u003cmodule\u003e-jvm` to `\u003cmodule\u003e` and vice-versa). Although IDEA will show an error in the settings because it detected a circular dependency, but code highlighting and compilation will still work fine.\n\nThe Seed integration also supports compilation to tmpfs which does not suffer from [this bug](https://youtrack.jetbrains.com/issue/SCL-13729).\n\n### File structure and root path\nWhile Bloop does not impose any limitations on how you structure your project files, IDEA does. For a Seed project to be valid in IDEA, a module's source and test files must have a common ancestor. If you have the directories `\u003cmodule\u003e/src/main/scala` and `\u003cmodule\u003e/src/test/scala`, `\u003cmodule\u003e/` would be their common ancestor. By contrast, this structure is not supported by IDEA: `src/\u003cmodule\u003e` and `test/\u003cmodule\u003e`.\n\nThe common ancestor is the module's *root path*. It needs to be set manually for each module using the `root` option.\n\n```toml\n[module.myModule]\nroot    = \"myModule/\"\nsources = [\"myModule/src/main/scala\"]\n```\n\nHere, the `root` path was chosen to be `myModule/` since this folder may also contain other non-source files.\n\n### Project dependencies\nIf you embed external projects using `import`, all external modules will be made part of the same IDEA project. This has the advantage that only one IDEA instance needs to be opened. As IDEA does not group those modules by subproject, it is advisable to use a prefix all module names from external projects.\n\nThis allows to run tests from different projects and make changes that span beyond project boundaries as well as the ability to use IDEA's refactoring tools.\n\n### JavaScript/native support\nIDEA does not support starting JavaScript/native projects or running their tests. However, other features such as syntax highlighting or refactoring work fine.\n\nThere are two related issues tracking the testing problems: [issue SCL-8972](https://youtrack.jetbrains.com/issue/SCL-8972) and [issue 743](https://github.com/scalatest/scalatest/issues/743).\n\nAs a workaround, you can open a terminal within IntelliJ and use Bloop, for example: `bloop test \u003cmodule\u003e-js`\n\n## Generate documentation\nSeed can generate an HTML documentation for your modules with the `doc` command:\n\n```shell\nseed doc example:jvm example:js\n```\n\nThe functionality is based on Scaladoc. For each specified module, it uses the corresponding Scala compiler. Scaladoc bypasses Bloop and performs a separate non-incremental compilation pass.\n\n## Packaging\nIn order to distribute your project, you may want to package the compiled sources. The approach chosen in Seed is to bundle them as a JAR file.\n\nTo build and package the module `demo`, use the following command:\n\n```shell\nseed package demo\n```\n\nThe default output path is `dist/`.\n\nIf the JAR file is supposed to have an entry point, make sure to specify `mainClass` on the module in your build file. Also, note that at the moment, only JVM modules can be packaged.\n\nThe library dependencies can be optionally bundled as separate files in the `dist/` folder, with the class path of the JAR file correctly set up. This allows you to have a self-contained version of your project for distribution. You can do so by specifying the `--libs` parameter:\n\n```shell\nseed package demo --libs\n```\n\nIf the module `demo` has a main class, you can run your program as follows:\n\n```shell\njava -jar dist/demo.jar\n```\n\n### Uber JARs\nThe approach of bundling dependencies as external files (commonly called Uber JARs or fat JARs) over to including them in the JAR has several advantages which are outlined [here](https://imagej.net/Uber-JAR).\n\nIn short, merging external JARs is non-trivial and oftentimes requires the intervention of the developer. For example, [sbt-assembly](https://github.com/sbt/sbt-assembly) needs custom Scala code to resolve conflicts.\n\nAlso, Uber JARs are large in size and it becomes difficult to share dependencies across different build versions and other projects on the client side.\n\nFinally, for clients it becomes harder to obtain a list of dependencies and their licences used in the application.\n\n## Updating\nThere is a command to check for version updates. It attempts to find suitable versions such that there are no incompatibilities between artefacts. For instance, for specific platforms a different version of a library may be required. You can run the command as follows:\n\n```shell\nseed update\n```\n\nIf you would like to use pre-release versions, you can also pass in this parameter:\n\n```shell\nseed update --pre-releases\n```\n\n## Publishing\nSeed can publish modules to Maven-style Bintray repositories. First, populate the build file's `package` section. Then run the following command:\n\n```shell\nseed publish --version=1.0 bintray:joesmith/maven/releases demo:js demo:jvm\n```\n\nThe credentials must be configured in the global Seed configuration:\n\n```toml\n[repository.bintray]\nuser   = \"joesmith\"\napiKey = \"\u003cAPI key\u003e\"\n```\n\nAlternatively, Seed reads the environment variables `BINTRAY_USER` and `BINTRAY_API_KEY`.\n\nSeed publishes sources and generates the documentation, which slows down the publishing process. If any of these artefacts are unneeded, you can permanently change the behaviour via `package.sources` and `package.docs` in the build file, or temporarily by passing `--skip-sources` and `--skip-docs` to the CLI.\n\nFinally, to depend on the published library in another project, add the Bintray resolver there:\n\n```toml\n[resolvers]\nmaven = [\"https://repo1.maven.org/maven2\", \"https://dl.bintray.com/joesmith/maven\"]\n```\n\nThe `--version` parameter is optional. By default, Seed reads the version number from the Git repository via `git describe --tags`. This allows publishing artefacts for every single commit as part of CI executions.\n\n## Performance\nOn average, Bloop project generation and compilation are roughly 3x faster in Seed compared to sbt in non-interactive mode. Seed's startup is 10x faster than sbt's.\n\nHyperfine 1.5.0 was used for the benchmarks. All tests ran on a [Hetzner CX21](https://www.hetzner.com/cloud) ([cpuinfo](https://gist.github.com/tindzk/ecc4422e406e4cf109fc891992d3bd03)) under Docker. The test project was [toml-scala](https://github.com/sparsetech/toml-scala). You can find the benchmark specification [here](.drone.yml) in order to reproduce the results.\n\n### Startup time\nSeed ran 10.56 ± 1.75 times faster than sbt.\n\n| Command | Mean [s] | Min…Max [s] |\n|:---|---:|---:|\n| `sbt exit` | 16.795 ± 0.995 | 15.230…18.097 | \n| `seed help` | 1.591 ± 0.247 | 1.099…1.879 |\n\n### Generating Bloop configuration\nSeed ran 2.95 ± 0.26 times faster than sbt.\n\n| Command | Mean [s] | Min…Max [s] |\n|:---|---:|---:|\n| `sbt bloopInstall` | 18.540 ± 1.135 | 16.923…19.986 |\n| `seed bloop` | 6.286 ± 0.404 | 5.848…7.028 | \n\n### Compiling project\nBloop ran 3.45 ± 4.08 times faster than sbt.\n\n| Command | Mean [s] | Min…Max [s] |\n|:---|---:|---:|\n| `sbt \"; clean; compile\"` | 61.720 ± 8.480 | 56.895…85.524 |\n| `bloop clean --propagate --cascade \u0026\u0026` | 17.894 ± 21.018 | 9.193…77.436 | \n| `bloop compile toml-js toml-jvm toml-native` | | |\n\nThis benchmark tested the compilation speed of JVM and JavaScript for Scala 2.12 and native for Scala 2.11.\n\n## Limitations\n### Plug-ins\nSeed does not offer any capability for writing plug-ins. If you would like to react to build events, you could use Seed in the server mode. To model the equivalent of sbt's tasks in Seed, you can define a separate module with [custom build targets](#custom-build-targets).\n\nIf some settings of the build are dynamic, you could write a script to generate TOML files from a template. A use case would be to cross-compile your modules for different Scala versions. Cross-compilation between Scala versions may require code changes. It is thinkable to have the `build.toml` point to the latest supported Scala version and have scripts that downgrade the sources, e.g. using a tool like [scalafix](https://scalacenter.github.io/scalafix/).\n\n### Publishing\nAt the moment, artefacts can only be published to Bintray. Sonatype support is planned for future versions.\n\n## Design Goals\nThe three overarching design goals were usability, simplicity and speed. The objective for Seed is to offer a narrow, but well-designed feature set that covers most common use cases for library and application development. This means leaving out features such as plug-ins, shell, tasks and code execution that would have a high footprint on the design.\n\nOn the other hand, Seed takes in features that improve a developer's workflow and would require external plug-ins otherwise. For example, the creation of initial projects or checking of updates are not essential features for a build tool, but improve the user experience and reduce time. Such features also take less work to implement than maintaining a plug-in infrastructure.\n\nSeed was designed from the ground up to be cross-platform. Furthermore, Seed does not impose much structure on your project, a folder structure or a certain way of handling modules (mono repositories vs. Git modules vs. published artefacts).\n\n## Contributing\nEvery new feature should fit into the architecture outlined in the design goals. Particular care should be given to the UI and documentation.\n\nThe output could use colours and bold/italic/underlined text. Also, components such as tables or trees may improve user experience. The user should not see any Scala errors, but instead human-readable error messages. As an example, invalid settings in the TOML are recognised and pointed out with a trace:\n\n```\n[info] Loading project ./build.toml...\n[error] The TOML file could not be parsed\n[error] Message: String expected, Num(42) provided\n[error] Trace: module → targets\n```\n\n## Development\nsbt takes the Git commit (`git describe --tags`) as the Seed version. This version can be overridden by creating a `SEED` file in the root folder.\n\nTo run all test cases, the Scaladoc bridges must be published locally for the current Seed version:\n\n```shell\n$ sbt\nscaladoc211/publishLocal\nscaladoc212/publishLocal\nscaladoc213/publishLocal\ntest\n```\n\n## Credits\nSeed achieves its simplicity by delegating much of the heavy lifting to external tools and libraries, notably Bloop and Coursier. The decision of using TOML for configuration and the build schema are influenced by [Cargo](https://github.com/rust-lang/cargo).\n\n## Licence\nSeed is licenced under the terms of the Apache v2.0 licence.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftindzk%2Fseed","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ftindzk%2Fseed","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftindzk%2Fseed/lists"}