-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Report to Raven when a component does not support the requested brand. #188
Conversation
// Therefore projects may have included it without setting the brand. | ||
let oLayoutException = false; | ||
if (allComponents.hasOwnProperty('o-layout')) { | ||
oLayoutException = parseFloat(allComponents['o-layout'].version) < 3; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would parseFloat work with a SemVer version such as 2.2.2?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would to confirm it's less than 3.
Is it possible to have some tests to cover this feature? |
@JakeChampion My intention is to add an integration test if we keep it (I'll create an issue with details). |
* Error when building a component for an unsupported brand. This is more helpful than broken CSS or a general Sass build failure. Relates to: #188
goal
SCSS compilation fails for
o-layout@v3.0.0-beta-1
and the master brand. We don't intent to fix it, as o-layout only supports the internal brand.Instead of a random SCSS compilation error:
OBS should throw a more helpful error:
gotchas
o-colors
have added support for different brands at different times. It's possible that a branded component has been used for an unsupported brand.approach
Throwing an error when a component does not support the requested brand is technically a breaking due to gotcha 3. I think it's a reasonable error to throw though if we can confirm it won't break our users builds. This PR will report to Sentry any builds which would fail. If none are reported, we may assume we can safely throw an error for real (I suggest at least a month, to allow the max-age of builds to expire; a month will also allow for sites with little traffic to make a request, as branding is quite recent this concerns me less). 👈 Feedback on whether this is a dreadful idea appreciated.