🎓 Add rich affiliations to frontmatter #535
Conversation
| frontmatter.affiliations | ||
| ?.filter((aff) => aff.id && !aff.collaboration) | ||
| .map((aff, index) => { | ||
| return { value: aff, ...indexAndLetter(index) }; |
There was a problem hiding this comment.
These changes will need to be consumed in the tex templates themselves; now, affiliations are objects instead of strings.
There was a problem hiding this comment.
There is also going to be a bit around @dressedfez's template that consumes the collaboration.
I think that they should be straight forward, however, we don't really have a way to version the templates which means this is a breaking change in that respect. Any better thoughts on how to handle it?
There was a problem hiding this comment.
I would be willing to introduce a versioning on my side. @rowanc1 which changes are necessary in the template?
There was a problem hiding this comment.
@fwkoch is going to open a PR!
collaboration.value --> collaboration.value.name in the template.
And then a small tweak to the frontmatter which will emit a warning on existing templates letting you know what to do.
The change works for both forward and backwards compatibility, in that it doesn't break the build, but the affiliation/collaboration will either not show up at all, or be [Object Object] if you are building with the new version and using the old template.
Now that is an object there shouldn't be any other backwards-incompatible changes!
| if (!Object.keys(lookup).includes(value.id)) { | ||
| if (Object.keys(value).length === 1 && value.id) { | ||
| // This is a single object with an ID that may be defined later | ||
| // Only assign if it is not already defined | ||
| lookup[value.id] ??= value; | ||
| } else if (!Object.keys(lookup).includes(value.id)) { |
There was a problem hiding this comment.
This is the only major change, if there is an object { id: 'ubc' } coming in, we don't want to overwrite anything, and in the initial stages of validation we also don't want to warn. This is a linking action.
| const value = validateObjectKeys(input, { optional: AFFILIATION_KEYS }, opts); | ||
| const value = validateObjectKeys( | ||
| input, | ||
| { optional: AFFILIATION_KEYS, alias: AFFILIATION_ALIASES }, |
There was a problem hiding this comment.
Added some affiliation aliases (including to support qmd).
| @@ -0,0 +1,6 @@ | |||
| --- | |||
| 'myst-frontmatter': patch | |||
There was a problem hiding this comment.
| 'myst-frontmatter': patch | |
| 'myst-frontmatter': minor |
I think we could do this as a minor release for frontmatter.
Removes name/institution check
fwkoch
force-pushed
the
feat/fm-affiliations
branch
from
90b14f0
to
6473064
Compare
|
We are making the changes to all of the templates, including @dressedfez's. The site templates will also need to be updated before we release, that will happen in the next few hours! |
This adds an affiliation object to frontmatter (instead of affiliation just being list of strings on each author).
Also, validating frontmatter, deduplicates affiliations across authors/pages/projects and normalizes them to a single list, referenced elsewhere by id.