Build pipeline stabilization

[bohoffi]

This PR targets some build pipeline issues:

• demo application budgets
• the libs dependencies according to the dependency check Lint rule
• unified usage of shared Empty type
  • type was renamed

[rainerhahnekamp]

Thanks @bohoffi, I've left some comments.

[rainerhahnekamp]

I am not sure about that to be honest. I know you just fixed a typo there, but do we really want to call it empty. I can remember of some eslint rule which says Empty should be Record<string, never>.

[bohoffi]

Yeah, eslint itself recommends Record<string, never>:

If you want a type meaning "empty object", you probably want Record<string, never> instead.'

What do you think about renaming the type to EmptyObject to create a better alignment between its name and its usage and use Record<string, never> to apply eslints recommendation?

[rainerhahnekamp]

Absolutely, would you actually create an alias for that or go directly with the {}?

I heard once that TypeScript is faster, when using aliases instead of "individual" types.

[bohoffi]

Personally I prefer a type alias as it ensures a consistent code style.
I've just checked what would happen when we'd use Record<string, never> instead of {} and it would prevent state patching as expected as the Record type wouldn't allow any updates.
Maybe I'm trying to overengineer it right now... when looking at its usage it represents that either do not have any specific expectations to the store or do not add anything to state/signals/methods.

I did some research about the performance and it depends - aliases can bloat up the bundle when massively used and inlined.

[rainerhahnekamp]

Can we leave that out for now? @mikezks, I think we need to find a better solution here. It shouldn't be that ngrx/store (and rxjs) come as dependency of the toolkit.

[mikezks]

Fully agree. I would not put store and signals into dependencies or peerDependencies.

I may put parts of the Redux Connector into a secondary entry point later to add a peer dependency on the store, but for now I would remove them again.

Edit: Signals into peer is fine, like currently defined.

[bohoffi]

The @nx/dependency-checks rule which brought up those changes offers fixers for missing or unused dependencies - the result would be exactly the same as with this PR.

With Mikes potential plan ahead I'll revert this change.

[rainerhahnekamp]

@mikezks does that actually work?

https://github.com/testing-library/angular-testing-library/tree/main/projects/testing-library/jest-utils has the same issue with a dependency to Jest. The fixed it by not including it into the package.json (like we have it now).