-
Notifications
You must be signed in to change notification settings - Fork 14
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
feat(typography & logos): locally hosted files #797
base: develop
Are you sure you want to change the base?
Conversation
Playwright test resultsDetails 391 tests across 132 suites Failed testssrc/components/dropdown/test/filter/dropdown.e2e.ts › tds-dropdown-filter › toggle dropdown visibility and select option two Skipped testssrc/components/table/table/test/expandable-row-autocollapse/expandable-row-autocollapse.e2e.ts › tds-table-expandable-row-autoCollapse › NEEDS FIXING: expanding one row collapses the others when autoCollapse is true |
This pull request is automatically being deployed by Amplify Hosting (learn more). |
8b2525f
to
412f112
Compare
@theJohnnyMe I think this will not work as you are hoping it to work. By doing this we are just copying the assets into the tegel build and does not mean that the asset files will be automatically hosted by the consuming application. To make it work you would need to point out the files from node modules or copy them over and then host them yourself. |
Hmm good catch @MartinPiq! I guess the consuming application has to explicitly copy these assets from node_modules to a location that is publicly accessible (e.g., a public or static folder) during the build process? The consuming application must make sure that the fonts are properly copied and served, which requires additional build configuration.
Maybe providing a fallback is valid?
|
A fallback font is a good idea but I think it would be preferable to have the local file as the fallback and the cdn as the primary source. If we don't have a fallback at all this will result in braking changes for all current users of tegel. I do however also think that having a double cdn setup would be the best option, one for within china and one for the rest of the world. This could be another opportunity to get in contact with Porsche as they have a setup that solves this. I think it would also be an interesting topic to move component code to cdn, similar to how Porsche have done it, as well, this would open up for caching tegel source code between all consuming applications and decreasing build size. |
Thinking out loud here, but maybe we could provide a configurable also? |
Thank you both for the great input. |
412f112
to
5354855
Compare
Quality Gate passedIssues Measures |
@@ -44,7 +44,6 @@ | |||
} | |||
|
|||
.tds-badge-text { | |||
font-family: var(--tds-font-family-semi-condensed-bold); |
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.
Why is this removed @theJohnnyMe?
Describe pull-request
The issue our users face is that we load font files via the CDN link set here in Europe, to be precise in Ireland.
That is a problem for users in China where they can not load files outside China.
We have placed the font files as assets in the mono repo and updated the stencil to copy them and make them available when shipping the code.
This way we increase the size of the package from 3.7 to 4.5MB but we make it more stable and independent. It is then really up to the application team to make sure they app is available to China or any other country.
The same issue was with Logotypes used in the Header and Footer components.
Issue Linking:
CDEP-
: CDEP-3530CDEP-
: CDEP-3085How to test
npm run build
onpackages/core
levelpackages/core/dist/tegel/assets
to see if font files can be found.Checklist before submission
npm run build-all
without errorsSuggested test steps
Additional context
I noticed that a lot of tests have failed visually. It seems to me that Docker was sometimes loading different fonts when taking screenshots or it was taking them too early so not all screenshots were 100% the same as when you load the storybook locally.
I have dropped all screenshots and created new ones to compare them here in PR so that others can test it and see if this branch gives a pass on unit tests. Let's see.
Plan is to make beta release, send it over to person from support and ask them to try it out.