- Issue created by @tyler36
- πΊπΈUnited States phenaproxima Massachusetts
Thanks! Any chance you could open a merge request for this?
Although this is technically a feature, I think it's too useful to not backport to 1.0.x, and it shouldn't affect the experience of our target audience (marketers) in any event. So, tagging for inclusion in a patch release.
- π―π΅Japan tyler36 Osaka
Hmmm ... I'm confused.
After following the instructions to fork the project, the project base already has a
.gitignore
.
So how do we merge out preferences with the project root? - πΊπΈUnited States phenaproxima Massachusetts
That's for the full development repository, not the Composer project template.
The zip file (which is also what you get when you run
composer create-project drupal/cms
) is generated solely from the contents of theproject_template
directory, so you want to put the gitignore in there. - πΊπΈUnited States phenaproxima Massachusetts
I need to put this somewhere more permanent where contributors can refer to it, but here's a quick write-up of how this repository works:
When you clone or fork this repository, you are not getting the same code base that an actual end user of Drupal CMS would get.
This repository is a monorepo, which means that it is automatically split out into many smaller repositories every time a commit is made to it. If youβre unfamiliar with monorepos, here is a little more info about them as a pattern: https://monorepo.tools/#what-is-a-monorepo
This repository, then, looks very different than what youβd get if you run `composer create-project drupal/cms`; it contains a lot of extra code, scripts, and infrastructure that are only needed by developers who want to contribute code to Drupal CMS itself.
If you run `composer create-project drupal/cms` (or download Drupal CMS as a zip file), you only get the code in the project_template directory.
We use DDEV as the platform for developing Drupal CMS, which is why there is a `.ddev` directory. When you start the DDEV project after cloning the repository (`ddev start`), a `composer.json` is generated by copying `project_template/composer.json` into the repository root, then overlaying the contents of `dev.composer.json` onto it, which installs dependencies only needed for development. This allows us to have the same dependencies as a βrealβ Drupal CMS project (without needing to duplicate anything), plus the extra tooling that we need.
- π©π°Denmark ressa Copenhagen
This would be awesome, finally getting a useful
.gitignore
in Drupal.I hope we can base it on the format reached in the β¨ Add a default `.gitignore` to composer project Active MR, and then add Drupal CMS specific stuff on top?
# This file contains .gitignore rules that are specific to the structure of the # Drupal recommended-project Composer template. Because .gitignore is specific # to your site and its deployment processes, you may need to uncomment, add, or # remove rules. # Ignore configuration files that may contain sensitive information. # # Typically, settings.php and related files are not committed to the # repository because they contain information such as the database # credentials that could be used to compromise a site. Sometimes, # a settings.php might be committed to the repository if it reads # sensitive information from environment variables or other sources. # ------------------------------------------------------------------ /web/sites/*/settings*.php /web/sites/*/services*.yml # Ignore paths that contain user-generated content. /web/sites/*/files /web/sites/*/private # Ignore SimpleTest multi-site environment. /web/sites/simpletest # Ignore directories generated by Composer # # See the "installer-paths" section in the top-level composer.json # file. # ------------------------------------------------------------------ /drush/Commands/contrib/ /web/composer/ /web/core/ /web/modules/contrib/ /web/themes/contrib/ /web/profiles/contrib/ /web/libraries/ # Generally you should only ignore the root vendor directory. It's important # that core/assets/vendor and any other vendor directories within contrib or # custom module, theme, etc., are not ignored unless you purposely do so. /vendor/ # Ignore scaffold files # # Note that the scaffold plugin may be used to automatically manage # a site's .gitignore files. If the `vendor` directory is ignored, # then one or more .gitignore files will be written to also ignore # any file placed by scaffolding. To avoid the creation of # additional .gitignore files, add all of the scaffold file # locations to the top-level .gitignore file, as shown below. # ------------------------------------------------------------------ /.editorconfig /.gitattributes /web/.csslintrc /web/.eslintignore /web/.eslintrc.json /web/.ht.router.php /web/.htaccess /web/INSTALL.txt /web/README.md /web/autoload.php /web/example.gitignore /web/index.php /web/robots.txt /web/update.php /web/web.config /web/modules/README.txt /web/profiles/README.txt /web/sites/README.txt /web/sites/default/default.services.yml /web/sites/default/default.settings.php /web/sites/development.services.yml /web/sites/example.settings.local.php /web/sites/example.sites.php /web/themes/README.txt # Other common rules # ------------------ # Ignore files generated by PhpStorm and VSCode .idea/ .vscode/ # Ignore .env files as they are personal .env
From https://git.drupalcode.org/project/drupal/-/blob/f6f9901f0524cb4d775a823...
All changes in the MR: https://git.drupalcode.org/project/drupal/-/merge_requests/5622/diffs - π©π°Denmark ressa Copenhagen
I couldn't open your file @tyler36, but I have created a suggestion, where I think it's supposed to be placed. It's basically the β¨ Add gitignore(s) to Composer-ready project templates Needs work MR, and then Drupal CMS specifics tagged on at the end, which could of course be reworked. But if this format is used, the resulting .gitignore could then easily be used for Drupal core as well, and be yet another positive side effect of Drupal CMS, where Drupal core is improved in the process.
- πΊπΈUnited States phenaproxima Massachusetts
Yeah - I don't think you'll be able to add it directly, but we can and should use the scaffold plugin to our advantage here. Since Drupal core already scaffolds a .gitignore into place, I think we should simply append our stuff to it. See https://github.com/drupal/core-composer-scaffold?tab=readme-ov-file#alte... for documentation on how to do that.
- π©π°Denmark ressa Copenhagen
I can't see a .gitignore in the root of a fresh Drupal 10 installation ... isn't that what β¨ Add gitignore(s) to Composer-ready project templates Needs work is about? This is from a fresh Drupal 10 installation:
$ tree -La 1 d10/ βββ composer.json βββ composer.lock βββ .ddev βββ .editorconfig βββ .gitattributes βββ README.md βββ vendor βββ web
Or do you mean using
web/example.gitignore
as a starting point, appending Drupal CMS specifics to that, and placing it as .gitignore in the root of Drupal CMS? - πΊπΈUnited States phenaproxima Massachusetts
Yeah - sorry, that's where I was going with that. I'm pre-caffeine.
- π©π°Denmark ressa Copenhagen
Thanks for confirming :)
It looks like we need to both rename and append, would something like this work? Though, I am not sure about the path to example.gitignore ...
"extra": { "drupal-scaffold": { "file-mapping": { ".gitignore": "example.gitignore", ".gitignore": { "append": "project_template/.gitignore", } }
- πΊπΈUnited States phenaproxima Massachusetts
That wouldn't be valid JSON syntax, but yeah -- something kind of like that.
- π©π°Denmark ressa Copenhagen
Thanks! I am not sure how to do local Composer repo testing, so someone else will probably have to take over ...