Closed rhuanbarreto closed 6 months ago
Typically this is done by writing the shared types to a package that is then consumed by any number of consumers.
I'm not sure this setting will change. It's primary use case was to stop apps importing components/utils/ets from other apps, as that breaks strict boundaries. Types are kind of a weird middle ground. If it's really a blocker, you can just disable it.
I disabled it. Just pointing out the view from a modern TS development workflow where frontends will be tightly integrated with backend types. Maybe the stack feature could be coupled to accept connections between frontend and backend applications?
Some examples:
Typically this is done by writing the shared types to a package that is then consumed by any number of consumers.
I'm not sure this setting will change. It's primary use case was to stop apps importing components/utils/ets from other apps, as that breaks strict boundaries. Types are kind of a weird middle ground. If it's really a blocker, you can just disable it.
I back this. If your frontend and backend need to share code you'd move that code into a separate package.
I disabled it. Just pointing out the view from a modern TS development workflow where frontends will be tightly integrated with backend types. Maybe the stack feature could be coupled to accept connections between frontend and backend applications?
Some examples:
Have a look at https://deepkit.io/library/rpc instead.
It's not sharing code. It's sharing types. The type is built into the backend application and you use in on the frontend client.
But you can close if you find this not relevant. At least I left the point here so other may relate in the future.
But keep in mind such pattern is growing fast in modern Typescript. Others may have the same desire.
Maybe the stack feature could be coupled to accept connections between frontend and backend applications?
This is a good idea, and a good middle ground. Let me attempt this.
Was easy to get working: https://github.com/moonrepo/moon/pull/1356
Can you try 1.22.3
It's not sharing code. It's sharing types. The type is built into the backend application and you use in on the frontend client.
Types are still code...
But keep in mind such pattern is growing fast in modern Typescript. Others may have the same desire.
That doesn't necessarily mean it's the right way to do things in a mono repo.
You do you.
@milesj it works like a charm! Also the VScode integration separating the stack is very good!
I think it's a good compromise.
And for closing the discussion about sharing backend to frontend code, Types are removed in runtime, so they are actually syntactic sugar in Javascript, which can be easily shared across projects. I'm also against sharing actual code between projects. But this emerging pattern needs this extra leeway until a better solution comes later.
The config
enforceProjectTypeRelationships
doesn't allow applications to depend on other applications. But nowadays in the JS ecosystem, there are now frontend applications that depends on backend applications in order to reuse its types for easy communication between them. I use Bun/ElysiaJS and eden treaty for doing that. But there are many other examples like tRPC, Fastify, Hono, etc.So the request is to allow applications depend on other applications if
enforceProjectTypeRelationships
is true