How to use common types for multiple applications in a project?

Question

typescript

Hello.

I have a project that includes an admin application and a user application. Essentially, they use common models, but for each application I define my own types (duplicated). Each application has its own folder in the project repository.

How can you avoid type duplication (interface definitions) between applications? I'm certainly thinking about writing an npm package and then installing it into both projects, but is it worth it? Or, in principle, is it normal practice to duplicate types between applications?

Answer 1

If you assume that something is a single entity, then there must be exactly 1 source of truth defining that entity. Types are the source of truth about the structure of your entities. If you operate on the same entities in two applications, then the types for them must be the same, otherwise it will be a DRY violation . But if in fact the entities are different, then even if they look the same, they cannot be combined, otherwise it will be a violation of SRP .
What can be done if the types describe single entities:
1. If both applications live in the same repository, then you can simply reuse the same modules in both applications. You can even put them in a shared folder and add an alias to it in tsconfig.json and in the build config.
2. If the application lives in different repositories, then the common code can be moved to the third repository and connected via git modules
3. And if the common code rarely changes, then splitting it into separate npm packages is a good idea. At the same time, it is not necessary to upload it to a public repository or buy a private one from npm, and it is not even necessary to install your own mirror (although it is convenient). You can simply pack the package into .tgz with the npm pack command , and then install it from this .tgz via npm i directly from the file system or from any http server. In addition, npm i can be done directly from the git repository at the root of which is package.json, but as for me, this is not a good idea, since git contains the sources, and the npm package should have ready-to-use (assembled) js code .
4. And finally, a single repository can also be organized into several packages using npm workspaces and lerna .
UPD:
You need to familiarize yourself with what you are referring to ...
In the Russian Wikipedia, in the article about SRP, a lot of nonsense has been written, which is not in the English version .
It's funny that like the English article, the Russian one also refers to Robert Martin, who defines this principle correctly (at least in those of his books that I read).
This is a very common misconception (OMG, I think I figured out where all these people who come in for interviews got this nonsense from...) Single Responsibility
Principlenot about the fact that the code does one thing or is responsible for one thing (what kind of responsibility can the text have?).
The principle of single responsibility is that each software entity has exactly one responsible person , and only this person is the source of changes in the code of this entity.