feat: migrate format from @guardian/types#220
Conversation
|
cc @JamieB-gu |
e42530e to
a8a0ada
Compare
src/format.test.ts
Outdated
| import { Design, Display, Pillar, Special } from './format'; | ||
|
|
||
| it('Design enum contains Article', () => { | ||
| expect(Design.Article).toBeDefined(); | ||
| }); | ||
|
|
||
| it('Display enum contains Standard', () => { | ||
| expect(Display.Standard).toBeDefined(); | ||
| }); | ||
|
|
||
| it('Pillar enum contains News', () => { | ||
| expect(Pillar.News).toBe(0); | ||
| }); | ||
|
|
||
| it('Special enum contains SpecialReport', () => { | ||
| expect(Special.SpecialReport).toBe(5); | ||
| }); |
There was a problem hiding this comment.
This keeps coveralls happy but I'm not sure that it's much use beyond that. Interested to hear any thoughts on a better approach or whether it's just not worth it.
There was a problem hiding this comment.
Ah, interesting that coveralls is really keen for you to run tests on what are essentially just type definitions - there's not really any logic to test there.
That said, testing the Theme enum might be useful, it's built as a compound of two other enums so I guess there's a chance for something to get broken there.
Otherwise, yeah I agree, this seems reasonable just to keep coveralls happy, but it's probably just running over ground that TSC covers anyway.
There was a problem hiding this comment.
Yes, it seems Jest will always report enums as uncovered, unless maybe you use these enums somewhere?
There was a problem hiding this comment.
They're actually good tests to have. It's not unfeasible that someone might modify the type and accidentally modify an existing Type due to a typo, or change the ordering and have that somehow break something
JamieB-gu
left a comment
There was a problem hiding this comment.
Nice! Thanks for doing this 🚀
One comment about obituaries - otherwise looks good!
Co-authored-by: Jamie B <53781962+JamieB-gu@users.noreply.github.com>
@guardian/types
src/format.README.md
Outdated
|
|
||
| ```js | ||
| import type { Theme, Format } from '@guardian/libs'; | ||
| import { Pillar, Special, Design, Display } from '@guardian/libs'; |
There was a problem hiding this comment.
i think we need to think about these names here. i know they have big significance in editorial, but examples like this:
import { Special } from '@guardian/libs';
import { Design } from '@guardian/libs';need to convey more to non-editorial devs i think. esp when it pops up in a list of possible imports in autocomplete (and in a generic org-wide library).
@JamieB-gu @oliverlloyd does something like this make sense?
import type { EditorialTheme, EditorialFormat } from '@guardian/libs';
import { EditorialPillar, EditorialSpecial, EditorialDesign, EditorialDisplay } from '@guardian/libs';There was a problem hiding this comment.
I see your point. Given that libs is dept-wide and not Editorial-specific the names do lose some context. Perhaps this is the best solution 🤔.
Although it's tricky because by making it more specific for non-consumers of these exports you're making it verbose/overly specific for the applications that do consume them. I don't have an idea for how to solve that though 😔.
Given that these may not live in this library for long do we want to do the large find-and-replace PRs on DCR, AR and IR to accommodate this change?
Apologies @sndrs none of what I've said is particularly conclusive, I've just added some more questions 🙈
cc @gtrufitt
There was a problem hiding this comment.
Yeah, import { Special } from '@guardian/libs'; lacks a lot of context outside of our bubble 🤔
EditorialSpecial is explicit but also a bit clunky. You'd probably end up import { EditorialSpecial as Special } from '@guardian/libs'; which I guess is fine but also a bit meh.
I'm guessing not but Is there an option to use a folder, like
import { Special } from '@guardian/libs/editorial';?
Another option is to do what DCR does (in about 80% of places) and use the Type suffix, like
import { SpecialType, PillarType } from '@guardian/libs';There was a problem hiding this comment.
the folder thing is an option but i'd rather avoid restructuring libs in order to accommodate importing ambiguous exports from types. e.g. we could potentially end up exporting two things with the same from different places which is even more ambiguity.
how do you feel about these instead?
import type { ArticleTheme, ArticleFormat } from '@guardian/libs';
import { ArticlePillar, ArticleSpecial, ArticleDesign, ArticleDisplay } from '@guardian/libs';it has the advantage of not implying that only certain teams should them and ArticleDesign.MatchReport reads clearly to me?
another option: if this is still unacceptably verbose, perhaps that's a sign these things shouldn't live in here?
There was a problem hiding this comment.
I think I'd actually prefer EditorialDesign to ArticleDesign, because Article is a Design, so you'll end up with ArticleDesign.Article 🙈.
another option: if this is still unacceptably verbose, perhaps that's a sign these things shouldn't live in here?
That's reasonable. It's possible that they don't. They're specifically Editorial concepts and this is meant to be a dept-wide repo. They're only being put here for temporary convenience until we can get them into CAPI. Maybe instead we should just not deprecate @guardian/types until that migration to CAPI has finished?
There was a problem hiding this comment.
ah right that's interesting. so it sounds as though something like EditorialContentDesign.Article is probably an accurate, unambiguous name (or something like it), but the amount of context you need to pack in to that name perhaps means it's not generic enough to live in here (whereas living in CAPI provides that context implicitly)
There was a problem hiding this comment.
I mean, really,
Articleshould beNewsorStandard
It probably should be Standard, you're right Oliver 🙄.
I don't think it should be News because a) it's not always used for news pieces, and b) News is a pillar 🙂.
There was a problem hiding this comment.
Just to clarify, is everyone happy for these values to change to
import type { ArticleTheme, ArticleFormat } from '@guardian/libs';
import { ArticlePillar, ArticleSpecial, ArticleDesign, ArticleDisplay } from '@guardian/libs';and Design.Article to become ArticleDesign.Standard or do we close this PR and figure out a better place for Format to live?
There was a problem hiding this comment.
I'm happy with ArticleTheme etc. 👍
Maybe the move from Article > Standard could be a separate PR?
There was a problem hiding this comment.
But also 👍 for Standard
|
🎉 This PR is included in version 2.6.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
What does this change?
@guardian/typesto@guardian/libsDesign.Obituary(https://github.com/guardian/types/pull/151/files)Why?
See guardian/types#136