How do you organize the simultaneous development of the library and the application that uses it?

Question

git

I often have a situation when, in the process of developing a project, a library is created right in it, which is essentially a separate independent solution and could be used in other projects. In other words, I want to cut it out of the main project and put it in a separate repository, pulling it into the project as a vendor. But due to the fact that I still have not found a convenient scenario for such a situation, many of my libraries either moved from project to project by simply copying files, or remained there, embodied in new projects by other implementations.
I believe that the problem is that as soon as a lib is cut into a separate repository, then it will enter the main project through vendors, and its further edits will be carried out within a separate project outside the main environment. It seems to me that this will add some complexity, especially at the initial stages, when there are many changes to be made to both projects. I thought that there might be some well-known strategy for such cases - for example, in some way you can tell the dependency manager that this package is your own project, and it needs to be cloned and considered simultaneously and as part of the main project, and as an independent.
Are nested repositories suitable for this purpose? In general, any advice on the topic is welcome.
UPD: I figured out how to simplify the question. How to keep the ability to make changes to the library directly in the main project without having to commit them to the repository until a certain point?

Answer 1

You can pull dependencies from the directory :
https://getcomposer.org/doc/05-repositories.md#path

"config": {
    "preferred-install": {
        "my/lib": "source"
    }
},

That. the venodr/my/lib directory will contain a git repository and it will be possible to make commits directly from there.
Personally, I settled on the crutch option :) I just make the venodr/my/lib folder - a symlink to the directory in which the project with this one is located. Something like the first option, but you won't have to clean up composer.json after yourself. As a result, it turns out like this:

• I am developing a library in a separate directory/project
  
• I make a symlink of the directory to the vendor and check the work in applications
  
• if everything is ok, I tag the release
  
• удаляю симлинк (не обязательно, но тогда в проекте библиотеки git будет в статусе detached head, что не критично)
  
• делаю composer update