Automatic File Headers
Code name:
auto-header
Automatically configures VS Code with customizable file headers based on your project’s license, company, and team information.
Also included automatically: repairs broken host paths in your git config and restores your SSH commit-signing key on every attach, on both local and cloud containers, with nothing to set up on your end — see
helpers4-commonfor how it works.
When to use this
Section titled “When to use this”Use this when you want every new file in a project to carry a consistent license/copyright header — SPDX identifier, project name, company, contributors — without anyone copy-pasting it by hand or forgetting it.
Alternatives:
- VS Code extensions like
psioniq File Headerdo the same job, but you configure the template yourself insettings.json; this feature derives the template fromprojectName/license/companyoptions and writes the VS Code config for you. - A CI-side license-header linter (e.g. a pre-commit hook or a dedicated Actions step) enforces headers on files that slip through, which pairs well with this feature rather than replacing it — this one generates headers as you create files, a linter catches anything that wasn’t.
Features
Section titled “Features”✨ Two header styles:
- Simple (default): Standard 3-line header with project, copyright, and license
- Custom: Your own multi-line header template
🔧 Flexible configuration:
- Project name (required)
- License in SPDX format (default: MIT)
- Company/organization name (optional)
- Copyright start year (optional, defaults to current year)
- Contributors list (optional)
🚀 Helper script: h4-init-headers command to initialize headers in any project
Requirements
Section titled “Requirements”This feature requires jq, which is provided by the common-utils feature.
All official devcontainers base images (mcr.microsoft.com/devcontainers/*) include it automatically.
If you use a minimal base image (e.g. ubuntu:latest), add common-utils first:
Installation
Section titled “Installation”Add to your .devcontainer/devcontainer.json:
Simple Header (Default)
Section titled “Simple Header (Default)”This generates headers like:
Custom Header
Section titled “Custom Header”After the container is created, initialize headers in your project:
This command:
- Reads your feature configuration
- Generates appropriate header settings
- Creates or merges with
.vscode/settings.json
Configuration Options
Section titled “Configuration Options”| Option | Type | Default | Description |
|---|---|---|---|
headerType | string | simple | Header style: simple or custom |
projectName | string | required | Project name for header |
license | string | MIT | SPDX license identifier |
company | string | optional | Company or organization name |
contributors | string | optional | Comma-separated contributor names |
sinceYear | string | current year | Copyright start year |
customHeaderLines | string | required for custom | Custom header lines (separated by literal \n). Supports placeholders: {{projectName}}, {{license}}, {{company}}, {{contributors}}, {{sinceYear}}, {{currentYear}}, {{copyrightYears}}, {{author}} (= company or projectName). |
Examples
Section titled “Examples”TypeScript Project with LGPL License
Section titled “TypeScript Project with LGPL License”Apache Licensed Corporate Project
Section titled “Apache Licensed Corporate Project”Custom Header with Specific Format
Section titled “Custom Header with Specific Format”What Gets Created
Section titled “What Gets Created”After running h4-init-headers:
.vscode/settings.json: Updated with file header configuration- Feature configuration: Stored in
/etc/h4-auto-header/config.json(system-wide)
Typical Workflow
Section titled “Typical Workflow”Integrating with Your Workflow
Section titled “Integrating with Your Workflow”Auto-initialize on Container Creation
Section titled “Auto-initialize on Container Creation”Add postCreateCommand to auto-initialize:
Multiple Projects
Section titled “Multiple Projects”Run h4-init-headers in each project directory:
The script will use the appropriate .vscode directory for each project.
Common License Identifiers
Section titled “Common License Identifiers”MIT- MIT LicenseApache-2.0- Apache License 2.0GPL-3.0- GNU General Public License v3.0LGPL-3.0- GNU Lesser General Public License v3.0BSD-2-Clause- BSD 2-Clause LicenseBSD-3-Clause- BSD 3-Clause LicenseISC- ISC LicenseMPL-2.0- Mozilla Public License 2.0
See SPDX License List for complete list.
Troubleshooting
Section titled “Troubleshooting”Script not found
Section titled “Script not found”Settings not applied
Section titled “Settings not applied”Headers not auto-inserting
Section titled “Headers not auto-inserting”- Verify file header support is installed and enabled
- Check
.vscode/settings.jsonexists and has correct config - Restart VS Code or reload window:
Ctrl+Shift+P→ “Developer: Reload Window”
Year not updating automatically
Section titled “Year not updating automatically”The headers are generated with fixed copyright years (e.g., 2024-2026) at the time the devcontainer is created. If you want the year to automatically update:
- Rebuild the devcontainer to regenerate the configuration with current year
- Or manually update the copyright years in
.vscode/settings.json
Integration with helpers4 Projects
Section titled “Integration with helpers4 Projects”This feature complements the helpers4 development environment:
- typescript: Work with properly licensed utility functions
- devcontainer: Ensure consistent headers across team
- action: Validate file headers in CI/CD pipelines
License
Section titled “License”Copyright (c) 2025 helpers4
Licensed under LGPL-3.0 - see LICENSE file for details
See Also
Section titled “See Also”Version History
Section titled “Version History”- v1.2.4: Added Rust (
.rs) file headers, using//line comments. - v1.2.3: Documentation only, no functional change — added a “When to use this” section with alternatives, matching the equivalent sections other features in this catalog already had.
- v1.2.2: Documentation only, no functional change — the previous wording sweep made the
JSON
descriptionfield far too long, shifting focus away from the feature itself onto the self-heal side benefit. Shortened to 5 words and kept generic (no implementation detail like “git config”), matching the original’s brevity and level of detail. - v1.2.1: Documentation only, no functional change — the self-heal callout above (and the
JSON
descriptionfield) led with internal jargon (“helpers4’s self-heal”) instead of the actual benefit; reworded to lead with what it does, with the full mechanism staying inhelpers4-common’s own README. - v1.2.0: Documentation only, no functional change — mentions that
helpers4-common’s automatic git-config self-heal (see above) now comes along with this feature. - v1.1.0: Switched from an inline copy of
helpers4-common’s bootstrap (user detection, apt helpers) to a directdependsOnon thehelpers4-commonfeature — no behavior change, just a single source of truth for that logic instead of a copy every feature had to keep in sync.
