Is it worth keeping frontend 3 similar projects in 1 repository and how to live with it?

Question

git

At the moment there is 1 site and 1 repository on bitbucket (it only has a frontend so far).
Styles are written according to the BEM methodology in SCSS, scripts in regular JS (JQuery), HTML is compiled from PUG.
The backend is in PHP and is a separate repository in its infancy.
Soon 1 more site will be created (and most likely 1 more after it), which will have many similar blocks.
Does it make sense to also keep a separate repository for the front and use it on 3 different projects, and keep the backend also separately?
The idea is that by adding some block, you can quickly start it on another site without copy-paste, as well as quickly fix common bugs in 3 sites at once.
How in this case to organize the work in terms of the git?
Is it really worth the bother? Is this by any chance an attempt to "shoot yourself in the foot"?

Approximate structure of the front

Answer 1

What you just described is called a monorepository (not to be confused with git modules). The practice is not new, but now it has gained popularity, especially in the frontend. The approach has supporters and opponents, but we will not move on to holy wars.
It can really be convenient. For example, to highlight the fourth project out of your three - containing, say, a component library and a storybook. I found a case for myself when working with react native and react native web.
Of the tools for organizing, I can advise Lerna, which has become the standard monorep. Or the same git modules, unless of course you know how to work with them.
In conclusion, I will say that several eminent companies practice this approach, on the scale of dozens of projects, and they seem to like it.

Answer 2

No, it's not worth it. Different projects - different repositories.

Answer 3

put everything in common in a separate package, cut everything there and share it between projects.
The package can be organized in any way - from npm and bower to your bike