This moves resolving of the config from the pattern constructor to the
init() method. The idea is that adding a part to a pattern is exactly
the same as adding a part to a design. In other words, late-stage adding
of parts would be no different as the config gets resolved after that.
This is currently broken in many different ways, but the unit tests
particular to this new way of resolving the config do pass.
We started out with following dependencies that are injected
(from) and now added dependencies that are merely required to
be drafted first (after).
This also adds further support for part-level configuration.
Restructured code a bit to handle all part-level config in one call.
Removed check in shorthand for debug as it's no longer used.
Updated tests to not fall over on different error message format in
newer NodeJS versions
Just call `pattern.addPart()` and pass it either:
- a part object with all it entails
- a draft method as first and name as second parameter
This will overwrite any existing parts without any warning
This is the first commit to tackle some exploratory work
in the context of discussion #2538 that deals with a number
of things, such as:
- Making it easier to attach parts to designs
- Making it easier to attach parts at run-time
- Simplify part inheritance into other designs
- Find ways to handle dependenices across designs
- Find ways to keep the part-specific config with the part
In this initial commit, I've update the Design constructor to
handle two different ways of calling it:
- legacy: new Design(config, plugins, conditionalPlugins)
- 2022: new Design(config)
I didn't want to call this the `new` way because that doesn't
age well, so I went with `legacy` and `2022` and this is how I
will refer to them from now on.
This is very much a work in progress and while I will create a PR
to keep on eye on the tests, I don't expect to merge this as-is.
