create asserts a default page width that update leaves alone
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start with resolveWidth in cmd/create/create.go and compare its default handling with the update path described in the issue. Read the principles documentation and the export and configuration guidance mentioned here. Done means one width policy is chosen, create and update agree or the exception is explicitly documented, and the relevant behavior is reflected in the project’s guidance.
Written by the indexing model from the issue text.
Description
create gives every new page a width of max when the file declares none. resolveWidth (cmd/create/create.go) walks --page-width, then frontmatter page_width, then the project file's page_width, and falls back to pagewidth.DefaultWidth when all three are silent. update does the opposite: an absent page_width makes no width request at all and leaves the live width alone.
That makes the two writing verbs disagree about what an absent field means, and it is the one thing keeping L9 (declared-metadata-is-asserted: a field the file declares is made true of the page; a field it omits leaves the page alone) from holding in both verbs. labels and page_status already hold in both.
The question is a decision rather than a bug fix:
- Leave Confluence's own default.
createmakes no width request when nothing declares one, matchingupdateandlabels. A new page gets whatever Confluence gives a page created through the API. - Keep
maxas house style, but make it a declaration. For example,exportand the docs recommendpage_width: maxinmarkfluence.yaml, andcreateasserts only what is declared. - Keep the current behavior and say in the principles doc that
createasserts a default width, as an accepted exception.
Whichever it is, update and create should agree, or the difference should be written down on purpose.
- Dominant language
- Go
- Stars
- 2
- Forks
- 0
- Avg merge
- 2h 50m
- Merged PRs (30d)
- 52
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from mozilla/markfluence
-
Difficulty 4/5 3-5 days Newbie friendliness 55/100
mozilla/markfluence#186 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
mozilla/markfluence#185 ·
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 55/100
mozilla/markfluence#181 · 1 comment ·
-
bug
Difficulty 5/5 Over a week Newbie friendliness 48/100
mozilla/markfluence#163 ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
mozilla/markfluence#162 ·
All issues in mozilla/markfluence
Similar issues
-
bug github_actions
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
registrystack/registry-stack#1393 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
JakeChampion/lang#10213 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
oasisprotocol/oasis-sdk#2523 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100