Proper way to install Drupal, missing vendor folders, example.gitignore

This is an excellent question. I think it is a documentation bug and not a support request. Thanks for raising it!

However, I'm not sure how to fix it. I'm setting the component to "base system" instead of "documentation" for the time being, so that the base system maintainers will notice this issue and hopefully respond. If they don't respond in a timely manner, I would suggest pinging either the branch maintainers or the "base system" maintainers in IRC and bringing this to their attention, and/or discussing there and then adding a summary of the discussion to this issue.

Perhaps this recent article helps http://blog.netgloo.com/2016/05/14/configuring-drupal-8-for-a-simple-git... ? Specifically the #deployment section.

This is really interesting. What I'm doing actually is to force git to add these files with -f option: git add -f core/vendor/assets but i'm not very happy with this solution.

What about:

!/core/assets/vendor

in .gitignore ?

I also think that #7 is best solution

#7 looks good for me.

/vendor

may be an option.

Talking with engineers here, they think changing vendor to /vendor in .gitignore would work too. But I got !/core/assets/vendor to work.

The engineers concern is that /vendor would work in other instances where vendor fails like it does in /core/assets/vendor.

/vendor works perfectly, thanks!.
I had issue with backup_migrate module because git was ignoring vendor directory inside the module.

what about

/vendor

to only ignore the root vendor directory?!

Okay, let's try to accelerate it...

I'm not sure what should the comment for the line say to be more descriptive and to avoid misunderstanding, but I would not recommend to comment the /vendor line out by default.

Look this https://github.com/hechoendrupal/drupal-console-launcher/blob/master/.gi...

When I add to gitignore:

!/core/assets/vendor - this works only at including the /core/assets/vendor directory

When I add to gitignode

/vendor - this works for all nested vendor directories:

core/assets/
modules/contrib/backup_migrate/vendor/
...

So I'm guessing that /vendor is preferable?

I recommended to install Drupal core and all modules via composer
https://github.com/drupal-composer/drupal-project

Replacing "vendor" by "/vendor" fixes the issue for me, it is very easy to overlook the core/assets/vendor folder when not working in an install profile environment, whether that's a best practice or not is another discussion.

I am not sure what is to be committed here.

There is only one patch attached in the issue (#14). example.gitignore file is often used as is on projects, just copied and renamed. So I believe example.gitignore file should be fixed, it's not just a documentation problem or so.

Thanks.

That would work only for sites using continuous integration.

Edited: this is a silly comment.

Oh I see, /vendor vs "vendor"...

I am more into #7.

Back to RTBC, I think /vendor and !/core/assets/vendor are specific enough and a solution needs to be chosen.

Adding the alternative patch that uses !/core/assets/vendor instead

I think we should take into account the fact that some contrib projects, libraries, etc. may contain vendor directory as well and ignoring them by default may be a problem sometimes (I'm not saying here that this is a good practice:)). See #12 for example.

- Updated issue summary
- Updated the second patch with clearer description.

I don't feel qualified to judge which is the best solution.

I would say as well, that "/vendor/" is much more secure.

There are many projects with vendor in it and it cause many problems.
the drupal composer template (https://github.com/drupal-composer/drupal-project/blob/8.x/.gitignore) uses "/vendor/" as well and worked very nice for every project I built on it.

I ran into the problem with ne normal .gitignore and missing jquery files through the project of another developer and it's really nasty.

Back to RTBC, I think any of the 2 alternatives are valid and this would avoid confusion on non-install profile environments.

Well less is more so I think making the vendor line specific is preferable. In #23 @cilefen expresses a preference for #7 but doesn't explain why.

For me, the intent of

# Core's dependencies are managed with Composer.
vendor

Is to ignore Composer's vendor directory. But it is also causes core/vendor/assets to be ignored. So it needs fixing. Otherwise some other module that adds a vendor directory that is not from composer but has something else with have the same problem.

With manual testing, /vendor/ or vendor/* works. Given #29 points out that drupal-project uses /vendor/ let's go for that since it has lots of usages on real projects.

As per @alexpott in #33, with an explanatory comment.

+++ b/example.gitignore
@@ -11,8 +11,9 @@
+# Core's dependencies are managed with Composer. Slashes used because we want to
+# ignore Composer's vendor directory, but not similar directories added by modules.
+/vendor/

Should break at 80. I would point toward core/assets/vendor explicitly.

So something like:

# Core's dependencies are managed with Composer. This directive is explicit to
# the root vendor directory so, for example, core/assets/vendor is not ignored.
/vendor/

Sorry...

Is there any reason behind core/assets/vendor naming? I find it ambiguous with composer vendor directory, what if we change to other than vendor (eg core/assets)?

I think the approach of ignoring the root /vendor/ directory (and not explicitly not-ignoring the specific /core/assets/vendor/ directory) is correct and what I've seen used successfully on several projects. This way vendor directories that are needed for core (and specific modules and libraries that might include vendor directories #26 #33) will not be ignored by default. #37 is worth considering, but would be out of scope for this issue.

+1 to #38. The only thing I'm not sure is /vendor/ vs /vendor.

Re: #39 . without the trailing slash, it will ignore both a directory matching "vendor" as well as a filename matching "vendor" as well as a symlink matching "vendor".

Because we are unlikely to ever have a file or symlink named vendor at the root, it wouldn't make much practical difference in this case. But it's a good practice if you know you want to ignore a directory and not also files and symlinks to include that trailing slash.

@manningpete
Checked some discussions and sometimes people symlink vendor because of several reasons. This case is specific though, and I don't think we should care about it and think about, if we should ignore it by default or not. So +1 to /vendor/

Version: 8.4.x-dev » 8.5.x-dev

No no no. Let's have it in 8.4.x, please! This change is not disruptive (it's just an example file) and unlikely will affect existing installations.

+++ b/example.gitignore
@@ -11,8 +11,9 @@
-# Core's dependencies are managed with Composer.
-vendor
+# Core's dependencies are managed with Composer. This directive is explicit to
+# the root vendor directory so, for example, core/assets/vendor is not ignored.
+/vendor/

I'd like to suggest "Core's PHP dependencies are managed with Composer." and that's all for the comment.

@cilefen
So, basically we returned to original comment.

Using fewer words is clearer.

The bits and pieces of education sprinkled throughout comments in the code helped me immensely when I was a beginner. Clarity is great but it's not the only worthy goal.

I respectfully disagree with the latest change.

Does anyone know of a way to regenerate these files once they are "gone"? The only way I can think of is to copy them from a fresh Drupal installation but I'd like to think there is a better way for this.

I also disagree with the change in #44. This is an example file. The explanation is already clear, and helpful to newcomers, who are the target audience for the file.

Nevertheless, it is currently wrong and is causing people to lose their core files, so I would rather have it fixed with the less helpful instruction than for it to sit here in the bikeshed for another month so I'm RTBCing.

IMHO it's a mistake to remove an entire sentence of supplementary information; the extra context about core/assets/vendor is useful (though perhaps the phrasing can be improved further). I suspect most people can't remember much .gitignore syntax; it's the kind of file most only edit occasionally.

I'd argue detailed inline/code comments/UI text reduce the need for documentation / tutorials / Q&As elsewhere, alternatives which can be inconsistent or don't age well. However, rightly or wrongly, I've struggled to make that case convincingly elsewhere in Drupal core.

I also don't see how "Core's dependencies are managed with Composer." is clearer than "Core's dependencies are managed with Composer. This directive is explicit to the root vendor directory so, for example, core/assets/vendor is not ignored."

I feel like someone with less experience with composer and/or git would appreciate the latter version.

When adding a new Composer package to "docroot/composer.json" and running "composer install", the package files get downloaded and installed properly under "docroot/vendor/new-package-name". However they fail to get added to version control due to the "vendor" line in "docroot/.gitignore".

Can this line be safely commented out if I actually need new Composer packages to be added to Git, committed, and pushed up?

I feel like core's "docroot/core/assets/vendor" directory should be ignored because I'll never need to add anything to it or change it in any way. However "docroot/vendor" should not be ignored because of the exact scenario I'm experiencing above, i.e. needing to add a new Composer package to version control. Is that assumption correct?

I don't have a build process that would run "composer install" in prod, which is why I'm needing to add and commit the new package locally.

Can this line be safely commented out if I actually need new Composer packages to be added to Git, committed, and pushed up?

Yes.

You may want to remove any git directories in /vendor before committing. Something like this untested composer variation may work for you.

Thanks @cilefen, I'm not intentionally trying to hack this thread, but it seemed relevant to the discussion.

Even after:

1. commenting out "vendor" in .gitignore and
2. running find vendor -type d -name .git -exec rm -rf {} \\; to remove all ".git" folders from vendor sub-directories

New vendor files do not show up as untracked changes waiting to be added to git.

I'm not sure how to commit something that still thinks it needs to be ignored.

Making changes to existing vendor files did show changes in my working directory.

Making changes to new vendor files did not show changes in my working directory.

"I'm not sure how to commit something that still thinks it needs to be ignored."

git add -f

I thought that too, but I get fatal: Pathspec '/vendor/package-name' is in submodule 'package-name'

I'll stop hijacking this post because this is trailing off as my personal Git issue, but it all was related to the .gitignore file ignoring vendor.

My journey leads me to these posts:

https://stackoverflow.com/questions/1084969/unable-to-track-files-within...

https://stackoverflow.com/questions/24472596/git-fatal-pathspec-is-in-su...

Thanks for your help @cilefen

Hi there! I'm new to Drupal, Composer and all this stuff, and as a newcomer I rely on instructions and guides a lot!
Last weekend I was trying to build my Drupal 8 landscape with Git using this, on the one hand, beautiful guide - https://www.drupal.org/node/803746 . On the other hand, I spent few hours trying to understand why my "copied" site has got some glitches. After some research I finally was able to find that core/assets folder was missing! Unfortunately the only way to fix that was to copy this folder from the "source" site.
Today I've found this thread and I see that there is no single way to resolve this issue. So maybe it would be a good idea to mention this issue in "Setting up the .gitignore file" part of the guide - https://www.drupal.org/node/803746 . So newcomers won't do mistake like I did?
Thx in advance!

Any resolution?

One more patch. Hope rule comment is good enough to proceed. I also made the first line of the comment more consistent with comments for other rules.

@gaurav.kapoor any of #36, #44 and #61 is correct solution, and you don't have to wait until patch is applied to fix your .gitignore file. We just need to agree on comment so it's clear and descriptive.

LOL. I already fixed it way before.

We just need to agree on comment so it's clear and descriptive.

That's what i wanted to know as well. Thanks @antongp

+++ b/example.gitignore
@@ -11,8 +11,11 @@
+# contain directories named "vendor" which should not be ingored by default.

spelling error "ingored".

I did find the message a little hard to parse, may I suggest the following comment?:

Ignore dependencies that are managed with Composer.
Generally you should only ignore the root vendor directory. It's important that core/assets/vendor and any vendor folders in contrib and custom modules are not ignored unless you specifically choose to do so.

@Darvanen thanks for finding a typo.
Here is one more version... I've changed text a little.
More feedback would be great!

+++ b/example.gitignore
@@ -11,8 +11,11 @@
+# that core/assets/vendor and any other vendor directory within contrib or
+# custom module, theme, etc., is not ignored unless you purposely do so.

Super nitpick, I don't know how much we care about grammar in comments?

The sentence makes more sense if you use "directories" and "are not ignored" because we're talking about multiple things.

I agree with @Darvanen in #66, a possible fix on commit or @antongp feel free to update the comment and I'll re-RTBC this.

I've been thinking about this some more. I'm not sure that this file should by default ignore vendor. It's much like the entry for core

# Ignore core when managing all of a project's dependencies with Composer
# including Drupal core.
# core

If you are using the tarball I'm not sure how relevant this file is for you. Mixing tarball and git feels weird and we also not recommending starting Drupal 8 projects from git anymore. That said this is a better default than the current one but I think we should review this file's content as part of the composer initiative. I think we need two versions of it - one for composer driver projects and one for people doing core contribution.

Anyhow, fixed the grammar on commit.

Committed and pushed 4a03584d2f to 8.6.x and 65ee0376cc to 8.5.x. Thanks!

Perhaps the paths to the sites sub-folders should be changed to web/sites, since that is the structure you get Starting a Site Using Drupal Composer Project Templates? (See attached file)