Remove Inter font assets from inclusion in downstream projects #353
Replies: 10 comments 3 replies
-
I've been adding the workaround snippet above to a bunch of my projects to mitigate Inter being included. This has become more of an issue since the The inter.css file will be downloaded by the browser, even if there is no Inter font usage in the app. imo - as Inter is not a part of Tailwind per se - it should not be a part of this gem. That's probably a separate discussion. Perhaps it could be an optional inclusion. |
Beta Was this translation helpful? Give feedback.
-
@stefanlindbohm I think we're open to a PR to improve this. Just to be explicit about the goals I think we're agreeing on:
The naive solution that comes to mind for me is to move the asset initialization from tailwindcss-rails/lib/tailwindcss/engine.rb Lines 5 to 7 in d52b49e into an app initializer that is generated during The only tricky part would be making the gem backwards-compatible with apps that don't have that initializer installed. WDYT? What ideas do you have? |
Beta Was this translation helpful? Give feedback.
-
I would remove inter font, maybe use |
Beta Was this translation helpful? Give feedback.
-
I agree. Here is a diff of the scaffolded views with and without Inter (without uses the default Tailwind font stack). It looks great without Inter!
True but maybe a major version bump and an education piece on how to add it back (or a link to add fonts in general) may work? |
Beta Was this translation helpful? Give feedback.
-
Thanks for the responses, everyone.
Sounds reasonable to me. I would personally add the goal that minimal complexity should be carried as part of this gem, with the assumption that the default font is just a starting point that will be customized by many/most projects. The point @robzolkos makes that Inter is not part of Tailwind per se is relevant here.
Right. Whether we can do breaking changes (and a major version bump) decides what paths we can take. Steps I can see for a non-breaking change:
A breaking change could be done by:
I would vote for doing the breaking change as that would simplify things as well as making these defaults explicit in newly setup apps (I suspect that many apps might already be using other fonts & are unknowingly deploying/loading unused assets). What do you think about this? |
Beta Was this translation helpful? Give feedback.
-
I think could make it work without the "breaking change", but I agree with @robzolkos and @stefanlindbohm . Some day this "baggage" will have to be dropped sooner or latter. |
Beta Was this translation helpful? Give feedback.
-
Circling back to this - I think dropping the inclusion of this font (which is not part of Tailwind) - could be part of an update when Tailwind4 is released sometime this year. It's a major version bump so would be a good time. |
Beta Was this translation helpful? Give feedback.
-
I noticed my user agent downloading Inter last week and figured this was something that came along with Tailwind itself (or maybe the typography plugin), so FWIW I was a little surprised to stumble on this issue/discussion and find it was part of the gem. (I share that just as a "path of least surprise" note -- it makes it feel like the font's inclusion by default might be beyond one's expected scope of the gem) If tailwind@4 is releasing soon, that might be a good time to drop it, but even in the meantime it'd be great to be able to exclude it without resorting to manually munging the precompile paths in an initializer (for fear someone forgets about it and years later it causes an issue) I wrote a slightly more conservative version of the initializer @stefanlindbohm contributed above as a workaround -- didn't want to risk it being forgotten on the next major bump: # config/initializers/remove_inter_font_from_tailwind_rails.rb
if Gem::Version.new(Tailwindcss::VERSION).segments.first < 3
Rails.application.config.to_prepare do
Rails.application.config.assets.precompile -= ["inter-font.css"]
Rails.application.config.assets.paths.reject! { |p| p.is_a?(String) && p.include?("gems/tailwindcss-rails") }
end
else
raise "Reassess the need (and safety) of this hack once Tailwindcss-rails is updated to Tailwindcss 3: https://github.com/rails/tailwindcss-rails/discussions/353"
end |
Beta Was this translation helpful? Give feedback.
-
Unfortunately the font wasn't removed from the gem as of the release of version 3. This discussion thread is really the only reference to this problem, as this discussion was originally an opened issue, so I suppose it shouldn't be a surprise that there hasn't been any movement or discussion on this. Perhaps the appropriate thing would be to open a PR. |
Beta Was this translation helpful? Give feedback.
-
Planning to drop Inter as part of the v4 upgrade/update, very soon. |
Beta Was this translation helpful? Give feedback.
-
This gem currently bundles the Inter font as part of its assets, which gets included in any project depending on it. As such it will also be picked up by
rails assets:prepare
and output into the public assets directory, whether the project uses the font or not. I'd like to propose these assets be removed fromtailwindcss-rails
or alternatively be included in a way that does not force assets into downstream projects.I know Inter is often used in Tailwind examples and as a starting point for smaller projects. This makes sense. But this gem should in my mind also be the preferred way for larger Rails projects using Tailwind, where Inter is unlikely to be the font of choice. In these cases, including the font assets with no way of opting out creates unnecessary clutter in those projects & deployments.
Possible actions
Workaround
I'm currently hacking my way out of these assets with the following configuration. I'm open to suggestions on how to do this in a cleaner way if possible. A clean & documented way to do this might remove the need for the proposed change.
I'd like to hear what you (maintainers) think about this. If this is a desirable change, I'm open to working on a PR.
Beta Was this translation helpful? Give feedback.
All reactions