About Those Invisible Files in Your Drupal Installation

Submitted by administrator on

Why you should care about “dot” files
Many Drupal (and PHP) projects include hidden files like .editorconfig, .gitattributes or .gitignore — they don’t affect page rendering, but they do contribute significantly to the developer experience, code consistency, version control hygiene and maintainability of your site.

If you’ve ever inherited a Drupal site, you know how messy it can become when there’s no guard-rails on style, whitespace, encoding or Git handling. The invisible files are your silent assistants.

Key files and how they work

.editorconfig
This file defines rules for editors/IDEs so that all team members (and your future self) will use the same indentation, line endings, charset and whitespace behaviour. Example excerpt:

root = true
[*]
end_of_line = LF
indent_style = space
indent_size = 2
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

Using this in your project means fewer style debates and fewer whitespace-based merge conflicts.

.gitattributes
This file attaches attributes or behaviour to path-names in your Git repository. A common use-case: the end-of-line setting for text files (so Windows vs Linux line-ending differences don’t cause issues). Example:

*.js    eol=lf
*.txt   eol=lf
*.json  eol=lf

It ensures consistency when multiple editors and platforms are involved.

.csslintrc
When working with CSS — especially in a Drupal theme context (like you are) — you’ll want linting to catch poor practices or inefficiencies. .csslintrc is a configuration file for the CSS Lint tool.

Example configuration might turn off rules like “adjoining-classes” or “zero-units” so that your team’s preferred patterns are allowed while you still benefit from automatic checks.

.htrouter.php
This is less common in production, but very useful when using PHP’s built-in web server (for local dev). The htrouter.php script handles routing of requests that would otherwise hit Apache/Nginx. If your dev workflow uses the built-in server, this file becomes handy — otherwise you may never see it.

.eslintignore, .gitignore … and others
There are many more “dot” files that silently keep your tooling clean:

  • .eslintignore configures what files/directories to skip in ESLint (JS linting)
  • .gitignore lists files that should not be committed (vendor folders, build artifacts, secrets)
  • Additional config files may govern CI/CD, formatting, packaging — the list grows as your project tooling matures

What this means for your Drupal project

  • You’re building for longevity: With consistent configs, future you (or future team members) will thank you.
  • You reduce “works on my machine” issues: When editor settings, line endings and encodings are aligned, merges and builds behave more predictably.
  • You subtly elevate your professionalism: Clients may never notice these files directly — but they experience the benefits through smoother deploys, fewer bugs, and cleaner code.
  • You prepare for growth: As you add tooling (Gulp, Sass, linting, USWDS, Single Directory Components) the config files become part of the scaffold rather than an afterthought.

Practical next‑steps (for you)

  1. At project root, ensure you include and maintain .editorconfig, .gitattributes, .gitignore.
  2. Add linting config files (.csslintrc, .eslintrc, etc) as your tooling stack grows.
  3. Document the “why” for your team or for yourself — when you come back months later, you’ll recall why this mattered.
  4. In your Drupal theme (especially if you’re using USWDS + SDCs like you are), make sure your build process honours these configs (e.g., your Gulp/Sass pipeline uses proper line endings, whitespace, etc).
  5. Celebrate the little wins: invisible files may not “look” like features, but they’re foundational.