Summary
APM currently uses:
apm.yml for the manifest
apm.lock.yaml for the lockfile
These two files are both YAML-based, but use different file extensions (.yml vs .yaml), which feels inconsistent.
Problem
This inconsistency can be slightly confusing for users, especially since both files are:
- YAML 1.2 documents
- Core project configuration files
- Expected to be committed to version control
Most ecosystems tend to keep naming consistent across manifest and lockfile (e.g. package.json / package-lock.json, pnpm-lock.yaml, etc.).
Proposal
Unify the file extensions for consistency. For example:
Option A:
Option B:
Notes
- The lockfile was renamed from
apm.lock to apm.lock.yaml for IDE syntax highlighting (per lockfile spec).
- However, the choice of
.yaml over .yml, and the inconsistency with apm.yml, is not explained in the current documentation.
Question
Was this inconsistency intentional?
If not, would you consider aligning the extensions for better consistency and developer experience?
Summary
APM currently uses:
apm.ymlfor the manifestapm.lock.yamlfor the lockfileThese two files are both YAML-based, but use different file extensions (
.ymlvs.yaml), which feels inconsistent.Problem
This inconsistency can be slightly confusing for users, especially since both files are:
Most ecosystems tend to keep naming consistent across manifest and lockfile (e.g.
package.json/package-lock.json,pnpm-lock.yaml, etc.).Proposal
Unify the file extensions for consistency. For example:
Option A:
apm.ymlapm.lock.ymlOption B:
apm.yamlapm.lock.yamlNotes
apm.locktoapm.lock.yamlfor IDE syntax highlighting (per lockfile spec)..yamlover.yml, and the inconsistency withapm.yml, is not explained in the current documentation.Question
Was this inconsistency intentional?
If not, would you consider aligning the extensions for better consistency and developer experience?