[Discussion] Refactor core and common packages for 6.0.0 release
See original GitHub issueThis proposal is a summary of multiple, already submitted issues. The main focus should be, how we proceed to fix these issues (which order) so we do not implement something, which has to be refactored for another issue anyway.
I’m submitting a…
[ ] Regression
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
[x] Refactoring
Current behavior
At the moment the core
and common
packages provide numerous problems:
@nest/common
depends on@nest/core
. Angular handles common package like a module internally. I think we should adapt this architecture.@nest/core
is too bloated. The only purpose@nest/core
should have is the DI system. Other than that it should not have any other functionality, like handling the web server as discussed in #531. In angular the core only depends on RxJS and zone.js
What is the motivation / use case for changing the behavior?
If these packages would get refactored, it would resolve mainly the issues #531 and #952. Since this is a major change, I think we should run it on a separate branch. I’d suggest start with
- Install TypeScript 3.x.x so we run on the newest version #868
- Extracting Express & Fastify from the core #531
- Refactor the common package, so it does not depend on the core anymore and create a
CommonModule
. #952 / #1060 - Build packages with yarn workspaces and get rid of the bundle folder #952 / #1060 / #658
=> See Roadmap
While we’re at it we should add a “strict” option in TsConfig.
The new dependency architecture would look like something like this:
These changes should be introduced as soon as possible. The more new features get introduced, the harder it gets to solve the named issues. That is why I propose this feature for the 6.0.0 release. 5.x.x should only introduce bug fixes, no new features until this issue is fixed
Issue Analytics
- State:
- Created 5 years ago
- Reactions:25
- Comments:17 (9 by maintainers)
Top GitHub Comments
In my opinion, refactoring express and fastify dedicated code as real adapters (https://en.wikipedia.org/wiki/Adapter_pattern) is very important.
For the moment nest/core is too linked (hardcoded) with express and fastify, but actual express and fastify adapters are not the same interface.
It makes it more complex to use an adapter other than express, and the code is heavier.
I’m in to help to solve this, is there already a branch to work on it ?
Slack would be particularly good for the maintenance team @BrunnerLivio – since it’s a smaller group, it wouldn’t get cluttered as easily.
I spoke with Kamil about a year ago about joining the core team (it was at about 1k stars at that point) but like I said I’d love to be a part of the team and start getting involved with Nest again.