[RFC]: Reduce package size #452
Replies: 10 comments 8 replies
-
|
Well... I'll go with Option 1, if that's the case. |
Beta Was this translation helpful? Give feedback.
-
|
@davelab6 any insights you can share on this issue? |
Beta Was this translation helpful? Give feedback.
-
|
@tay1orjones Option 1 of the two. |
Beta Was this translation helpful? Give feedback.
-
|
@tay1orjones Separate repos for the different sub families has always been my preference. |
Beta Was this translation helpful? Give feedback.
-
|
One thing that's changed since I opened this proposal is that Nx has taken over stewardship of lerna. This makes lerna a viable contender and probably the default choice for monorepo instrumentation as it's what both the |
Beta Was this translation helpful? Give feedback.
-
|
There is a question as to the organization of packages. I think it makes sense to just follow the way they're organized and delivered from @BoldMonday
I think it's worthwhile to avoid putting jp/kr/tc/sc into a single |
Beta Was this translation helpful? Give feedback.
-
|
This would mean that |
Beta Was this translation helpful? Give feedback.
-
|
cc @mjabbink see above |
Beta Was this translation helpful? Give feedback.
-
|
Following the current folder structure makes sense. That is also how fonts are listed in font menus, for example. |
Beta Was this translation helpful? Give feedback.
-
|
And splitting KR/JP/SC/TC into individual packages makes perfectly sense as well. |
Beta Was this translation helpful? Give feedback.
-
|
我路过的，有些问题想说/ (I have read #554 (comment))
“Thai Looped” may belong to “Thai”? |
Beta Was this translation helpful? Give feedback.
-
|
This makes sense to me. My only concern is not having two sets of sans, one with CY/GK and one without. A few years back, we found that some teams didn’t need to include Cyrillic and Greek and needed the font files within a specific size limit. This means we have a sans |
Beta Was this translation helpful? Give feedback.
-
|
Something like below?
|
Beta Was this translation helpful? Give feedback.
-
|
I'm not opposed, but it would be best if the source on box delivered from @BoldMonday matched this folder structure if we did this. |
Beta Was this translation helpful? Give feedback.
-
|
I think this needs more consideration. This proposal also means that font naming inside of the fonts needs to be distinctive between fonts There are split font files currently for Sans where Latin, Cyrillic and Greek are already separated. Is that not sufficient? |
Beta Was this translation helpful? Give feedback.
-
|
maybe like— |
Beta Was this translation helpful? Give feedback.
-
|
You’re totally right @BoldMonday. I have not had “extended” in my brain for a long time, but yes, we can't use that name.
|
Beta Was this translation helpful? Give feedback.
-
|
@tay1orjones Let’s go with the above. |
Beta Was this translation helpful? Give feedback.
-
Background
The current package,
@ibm/plexhas recently increased beyond the threshold of GitHub's large file size limit of 100 MB, #453. Due to this, the compressed package binary (used for yarn cache for instance) is now ~170 MB and too large to be included in the project without enabling LFS. Yarn cache does not support LFS. We need to provide a way for these projects to include the package.Below are two options to consider to resolve this.
Option 1 is my recommendation after consulting various maintainers.
Option 1: Provide per-family packages
We would like to provide packages for each individual family within Plex in addition to the existing
@ibm/plexpackage. These new packages would be named using hyphenated suffixes:@ibm/plex@ibm/plex-sans@ibm/plex-sans-condensed@ibm/plex-serifThese packages will help provide a more concise way to include only specific assets within a project instead of the entire font. Additionally, the individual packages will be smaller, facilitating use within projects that vendor dependencies or use Git for dependency caching.
With per-family packages, projects could opt to install
@ibm/plexas before, or instead install only the relevant families their project uses.Technical Deep Dive
To facilitate per-family packages the repository needs to be reconfigured to house the multiple packages under the one repository, known as a monorepo.
Additionally, tooling must be supplied to facilitate the management of the monorepo. Recently Carbon looked into updating it's monorepo tooling and found solid candidates with using yarn workspaces supplanted by
nxorturborepo.Further, the packages within the monorepo need to be versioned and published to npm. Turborepo's docs outline some good candidates:
Questions
complete, or can we just includesplit?splitas this should cover the primary use cases. We can expand what is included in each package by request.@ibm/plexwould not changeOption 2: Remove certain families or file types
The bulk of the file size weight is consolidated within just a few families:
We could remove Japanese and/or Korean to reduce the filesize. These could then be published as their own packages. We would likely still need a monorepo set up to manage this, which then negates any work/cost savings. If we're going to publish a different package for JP or KR, why not do it for all families?
Removing certain file types is another approach, but it doesn't result in a large savings:
In either case the experience using Plex assets through
@ibm/plexwould be fragmented. It no longer would be the source of all assets. Additionally this would require a breaking change version as we'd be removing assets, which would not be backwards compatible.Questions
@ibm/plexwould changeBeta Was this translation helpful? Give feedback.
All reactions