Full project life cycle: html, css, js > php, templates, changes, reuse?

Question

PHP

In creating sites, it is convenient to use and maintain existing developments, templates, libraries, blocks.
What approaches do you use to reuse code and control all the stacks during the life of the project?
For example: we create a layout (for example, using bootstrap or our own running blocks on jade, plus styles, plus javascript), we get a bare frontend, then we “pull” it onto the CMS, therefore a gap is formed between the generated templates (for example, everything is assembled using Gulp, connecting forms, written role, scripts, etc.).
If in the future, you need to change something in the project, appearance, styles. It’s not possible to simply rebuild the frontend from the source, which means you need to edit the pens, the project is overgrown with edits, it’s hard to maintain, flexibility / modularity is lost, etc.
Ideally, I see universal templates: for example, to add a carousel to the project, there is a folder with files, php, js, css, which we connect quickly and easily by making small necessary changes. At the same time, we get the assembled project as an output.
He likes BEM in this regard, but it is quite difficult to work at full speed from a swoop to both BEM and PHP.
I tried to implement it using build systems, but the plug is formed after stretching (I haven’t touched jadePHP yet).
In general, I decided to consult, who works as? On my own experience, I met only an ancient approach, we generate statics, then a stretch, further life / edits under version control "live" with fingers crossed.

Answer 1

The approach has long been developed: package managers. For the frontend, this is npm/bower (or maybe component, but this is a slightly broader thing), which you can slip the address of a private git/hg repository into. Just add node_modules and bower_components to .git_ignore.
Another option is git submodule, but that would be more painstaking.

Answer 2

The current approach is quite confusing if you know all the charms of BEM.
Now we are doing:
0. The designer drew the layout
1. We make up html with our hands: a.html
2. we write styles with our hands: a.css
3. we write with our hands js: a.js
4. We pass this all to the backender and it
: splits into templates, from a.html gets A.tmpl, B.tmpl, C.tmpl, ...
6. Adds styles to his files, and often also splits them into parts: A.scss, B.scss, . ..
7. Adds js, and also often breaks: A.js, B.js, C.js
8. Some backend assembles a page from pieces of templates, and often creates css, js only from the necessary pieces
And then: A new one has arrived layout. And what to do?
And BEM solves the problem in this case, because it has a technology stack that allows the layout designer to work immediately with templates and parsed js/css (less/sass/stylus) files.
In practice, it turns out like this:
0. Layout.
1. The layout designer looks at the layout and breaks it into pieces (components) at once;
2. Writes bemjson (or jsx) instead of html;
3. Creates templates, styles and js for each of the blocks;
4. Transfers all this to the backend programmer (usually through git, because it is more convenient this way);
5. The backender uses these files without changes to generate the page, and simply generates the bemjson (or jsx) described by the layout designer.
And oh MAGIC, they can work on the project in parallel, even if a new layout comes along.
C php really has nuances that are hard to see, simply because there are not a large number of users and the stack is not well established.
We use a bike that assembles everything ourselves, and are almost ready to switch to enb using bh-php.
The big problem, as it turned out, is the use of declarative template engines - layout designers do not immediately enter what and how. But when they moved in, I don’t know those who return to the imperative ones (such as mustaches, jade, smarty, etc.).
You can start at https://github.com/bem/project-stub/tree/php-bem-bh and ask questions on the forum https://ru.bem.info/forum/ - people will share their stories.