We then run this as part of the build step, then run tsc with the
original project file to get the side effect of emitting the source
files. Since the `test/tsconfig.json` has `noEmit: true`.
Ok so this is pretty shit, i hate the integration test suite now.
The reason why we return the test functions with `as any` in the
hello test is because we had to remove `Record<string, any>` from
mocha's test context interface, otherwise the interface would
have been completely useless. Maybe there is a ts setting though
to not infer any from `this` at all? and just ignore those properties.
The tsconfig.json situation is a bit weird, i don't understand why
it's in this situation. However, it seems like we can try to
https://github.com/jaredpalmer/tsdx/issues/84#issuecomment-489690504
use this workaround so that ts language features work in the test
directory.
I think we should focus on doing as little effort as possible getting
these tests into working condition. If something is too complicated,
it will need removing. If we need to make additional tests,
this entire integration tests directory should be moved
to a legacy-integration directory and we can start afresh.
We should also ideally not integration tests as much as possible
and try to reuse the unit helpers from MPS.
This is even going to be critical later on.
We needed to add support that enabled this into MPS.
the `MatrixDataManager` has been removed because it is
redundant with the `SchemedDataManager` from MPS.
Still need to figure out the plumbing of starting this and the report poller
in integration tests and from index without being started from Draupnir's class.
We had to change the old prompt for accept since it depended on the matrix emitter.
In order to remove the dependence on the event emitter, then we had to get
rid of the entire continuation which waits for the prompt and make it entirely
event driven instead.
Changes made while here were also emoji for numbres and no longer having timeout
for prompt arguments.
gnuxie