Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

outside vendor folder #5

Open
lukasniestroj opened this issue Jan 31, 2023 · 13 comments
Open

outside vendor folder #5

lukasniestroj opened this issue Jan 31, 2023 · 13 comments

Comments

@lukasniestroj
Copy link

Hi @TomasVotruba,

is it possible to set the vendor dir by command or configuration?
I have a TYPO3 Setup and want to patch extensions, they are copied to a different folder during composer installation.

So in my case I would like to make patches in /private/typo3conf/extensions

@XjSv
Copy link

XjSv commented Mar 15, 2023

I am running into the same issue using Drupal 9. Modules are installed into a different directory and patches for those are not generated.

@arderyp
Copy link

arderyp commented Mar 23, 2023

@XjSv doesn't drupal copy the files from vendor? if so, and this isn'tworking, the patching must be executed after drupalcopies the files from composer. Sounds like it might be the same issue for @lukasniestroj

@TomasVotruba, I'm wondering if composer.lock gets upgraded when we patch a composer.json in a vendor package. for example, the vendor package says it supports php:7.4, but I add a patch to make the package 8 compliant, including a change to composer.json... will my own composer.lock reflect the downstream change on the vendor package's composer.json?

@XjSv
Copy link

XjSv commented Mar 23, 2023

@arderyp You are correct, after a second look it seems like there is no issue here. When applying patches it seems to be working correctly. The confusion on my end was about making patches v.s. applying patches.

In my case I could not make a patch because the composer installed modules are also in the .gitignore file. So when I make a change to it, it's obvious why I cannot create a patch for a file that git is ignoring. Since a patch is basically just the output of a git diff.

@arderyp
Copy link

arderyp commented Mar 23, 2023

@XjSv im not sure I totally follow your comment about .gitignore. I know most people (should) ignore vendor/. But I don't think that should prevent you from using this patch library.

Is everything working for you okay, or are you still having an issue?

@XjSv
Copy link

XjSv commented Mar 23, 2023

@arderyp My Drupal 9 composer build is a little complex. I am also using oomphinc/composer-installers-extender to install different types of modules into different directories. Here is an example:

"extra": {
    "installer-paths": {
        "web/core": [
            "type:drupal-core"
        ],
        "web/modules/composer/{$name}": [
            "type:drupal-module"
        ]
    },
}

Once everything is installed and then I go and modify a file inside any of the packages here: web/modules/composer/{$name}, I cannot create a patch for those changes.

@arderyp
Copy link

arderyp commented Mar 23, 2023

@XjSv I'm still confused. I believe your Drupal composer setup is pretty normal for D9

Composer downloads dependencies to vendor/. You should create a patch from vendor. This library should then pick up that patch from vendor and re-implement it every time you run composer install. The patched vendor files should then be copies to your web/ locations.

Again... is the process working for you or you still have problems?

@XjSv
Copy link

XjSv commented Mar 23, 2023

@arderyp It's totally possible that I am not using it correctly. But in my case there is no copy of the module outside of web/modules/composer/{$name}. Meaning that there is no copy of it in the /vendor directory that I can change. Of course there are other dependencies in the /vendor directory but no drupal modules.

@arderyp
Copy link

arderyp commented Mar 23, 2023

Sorry @XjSv i think you are correct and I am incorrect (conposer isn't copying files from vendor it's installing them outside of vendor from the get go)

I will test this later today and get back.

@arderyp
Copy link

arderyp commented Mar 24, 2023

hey @XjSv I think the best bet is for you to not use this package, and instead follow the instructions here: https://gorannikolovski.com/blog/how-to-upgrade-drupal-9-to-10#how-to-install-modules

That is working for me.

@XjSv
Copy link

XjSv commented Mar 28, 2023

@arderyp Thanks for your help but due to the issues explained, I stopped using it from the beginning, since it never worked for my specific use case. I was just trying to document the issue here in hopes that you or someone else could make it better for future use. I also thought that maybe I was using it wrong and you or someone could explain how to use it correctly.

The link you posted simply describes how to upgrade from Drupal 9 to 10 using composer and how to use patches with composer in general. I don't have this issue. I am already using a couple of community patches for a couple of modules.

Since this issue is already opened, maybe the best thing to do here is to update the documentations/readme to mention that if your packages are installed outside of the vendor folder then this wont work.

@arderyp
Copy link

arderyp commented Mar 29, 2023

@XjSv I guess I'm still confused what your actual problem is. If you are trying to patch anything pulled from composer, even if you use composer-installers to have those packages installed outside of vendor/ (for example in web/core/ or web/modules/contrib/ in the case of Drupal) the composer-patches package will allow you to do that.

If you are trying to patch code files that composer doesn't know about, then maybe it won't work or will require some customized workarounds.

I was interpreting your issue to be "I can't patch my Drupal composer dependencies that happen to live outside vendor/", which is indeed possible as outlined above. I am, for example, using the aforementioned packages to patch contrib modules that composer installs to web/modules/contrib/, not vendor

@make-me-a-websiteDOTnet
Copy link

make-me-a-websiteDOTnet commented Jul 25, 2023

To try and make things clearer:
by default Drupal uses a custom scaffolded composer.json file which use composer's plugin "composer/installers".
This allows certain dependencies (eg modules & themes) to be installed outside the usual vendor directory.

When you try to use symplify/vendor-patches on those, the modifications are not detected (I guess it only scan the vendor dir..?) This is sad since patching Drupal's modules is a pretty current practice.

To fix this, you would need to have this library scan also the paths provided in the "installer-paths" key in composer.json file that use "composer/installers".

For ex in drupal's composer.json it look like this =>

  "installer-paths": {
         "web/core": [
             "type:drupal-core"
         ],
         "web/libraries/{$name}": [
             "type:drupal-library"
         ],
         "web/modules/contrib/{$name}": [
             "type:drupal-module"
         ],
         "web/profiles/contrib/{$name}": [
             "type:drupal-profile"
         ],
         "web/themes/contrib/{$name}": [
             "type:drupal-theme"
         ],
         "drush/Commands/contrib/{$name}": [
             "type:drupal-drush"
         ],
         "web/modules/custom/{$name}": [
             "type:drupal-custom-module"
         ],
         "web/themes/custom/{$name}": [
             "type:drupal-custom-theme"
         ]
     }

This would probably benefit a lot of other projects outside drupal...
Anyway, thanks for this great library !!

PS: rereading your message above @arderyp you imply that this should not be a problem, but then how do you get vendor-patches to detects the changes ? I can't find any documentation and this does not seem to work with a vendor/bin/vendor-patches generate (while it works with an "usual" vendor dir library)

@arderyp
Copy link

arderyp commented Jul 26, 2023

I do not use vendor/bin/vendor-patches

I followed the instructions I linked above and that system is working well for me

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants