Open honzajavorek opened 7 years ago
When this happens, investigate whether lerna wouldn't help with managing. (Thanks @XVincentX for the tip.)
When you say multiple projects, do you mean multiple repos?
That is an implementation detail to be decided. I mean multiple packages in the first place.
I'm going to make this a ticket tracking our "monorepo" efforts, which are currently under-documented and scattered all over our repositories.
I think the initial ideas were formulated around this conversation https://github.com/apiaryio/dredd/issues/600#issuecomment-324887713, then it was further discussed in Apiary internally (Slack link to the initial message, for employees) and also externally with the original Dredd author @netmilk. This issue was created to make the intention public, but I'm not sure it sums up all the reasoning sufficiently. Issues https://github.com/apiaryio/gavel.js/issues/126 and https://github.com/apiaryio/dredd-transactions/issues/252 were created, but unlinked from any other mentions of the decisions behind. There are additional mentions of the "future monorepo" in https://github.com/apiaryio/dredd-transactions/issues/105#issuecomment-346317514 or in https://github.com/apiaryio/dredd/issues/1186. The v7 of Dredd Transactions is one of the first steps in the effort, splitting parsing and compilation into two distinct modules (packages, if you want).
dredd
and dredd-transactions
projects makes the development more difficult. To have those two under one roof removes overhead for both the maintainers team and contributors.dredd-transactions
project itself didn't start with clear interfaces. When it was refactored to have clear boundaries, it actually ended up to be two things - API description parser, and transactions compiler. This makes it at least three libraries in the monorepo scenario: dredd
, dredd-parse
, dredd-compile
dredd
project itself is getting harder to maintain over time, as it consists of a series of monolithic classes entangled together. The intention of the maintainers was to find clear boundaries between various areas of code, to document the boundaries, and to give names to the areas: dredd
(CLI), dredd-core
, dredd-hooks
, ... While this can definitely happen only on a level of separate folders with well-specified interfaces, having a monorepo in place could accelerate the impacts and force both maintainers and contributors to keep the areas separated and the interfaces properly documented, with the benefit of having these as packages somebody can use and build on top of.npm link
multiple projects, etc.dredd-validate
or something like that might be way too radical, I think we agree that having Gavel still as a gavel
package, but managed within the monorepo doesn't hurt anyone's feelings and at the same time it makes everyone's life easier. Dredd monorepo was always considered with the intent that all the individual packages are reusable LEGO pieces published to npm, so having Gavel there fits the overall design.gavel-spec
is used in gavel
, dredd-example
is used in dredd
, etc.) Again, dropping overhead, making synchronization simpler.gavel2html
project into the monorepo until it is used within Dredd. So far it renders diffs for Apiary. If we ever use it for e.g. rendering Dredd's console output or Dredd's HTML reporter, I don't see why it should be in the monorepo.dredd-transactions
to two subprojectsyarn
etc. (get inspired by the work done on API Elements, ask around in @apiaryio/adt for help)dredd-transactions
as two separate packagesgavel
and gavel-spec
)dredd-docker
, dredd-hooks-template
) - note: do NOT include dredd-example
, which should stay as a separate repo mainly for discoverability and to isolate the showcase of CI setups from the rest of Dredddredd
, dredd-core
, dredd-hooks
For Dredd it would make sense to split into multiple projects:
dredd
- command line tooldredd-core
- the core functionality of Dredd, without the command-line interfacedredd-hooks
- support for hooks, communication with hook handlersdredd-transactions
- parses API description and outputs a list of HTTP transactions to executeThis would make easier to use Dredd also in other environments than CLI (imagine all kinds of integrations, such as the one @XVincentX did for Visual Studio Code).