Because as it stands, having those parts as separate packages is unnecessarily overengineered. I first started with the criteria package to be on its own as I thought it would be a good idea for it to be as standalone as possible.
Turns out I then later had to introduce the "common" package as I needed to share EntitySelection logic between core & criteria. I'm sure there will be many more such cases, so I'd rather have everything within one package again.
Additionally, IDE / Jest support is a bit better:
Find References will work even without having first opened all the libs
running tests will be easier (don't have to run tests for both core + criteria at the same time all the time)
Jest doesn't rerun core tests in watch mode if criteria code changed. I always have to trigger a file change within core for it to rerun the tests.
Notes
My current plan for the "end" result is to have the following packages:
@entity-space/core
required on both client + server
@entity-space/browser
@entity-space/node
@entity-space/utils
doesn't need to be explicitly installed by user
is its own package so as to not pollute global auto imports while still giving me (or potential users of this library) to opt in using it within apps
What
take the following packages:
and move them into the @entity-space/core package
Why
Because as it stands, having those parts as separate packages is unnecessarily overengineered. I first started with the criteria package to be on its own as I thought it would be a good idea for it to be as standalone as possible.
Turns out I then later had to introduce the "common" package as I needed to share EntitySelection logic between core & criteria. I'm sure there will be many more such cases, so I'd rather have everything within one package again.
Additionally, IDE / Jest support is a bit better:
Notes
My current plan for the "end" result is to have the following packages: