search

SymfonyCasts / tailwind-bundle

Delightful Tailwind Support for Symfony + AssetMapper
https://symfony.com/bundles/TailwindBundle/current/index.html
MIT License
83 stars 20 forks source link

Working with Github rate limits #43

Closed jasperweyne closed 5 months ago

jasperweyne commented 10 months ago

TailwindBundle will query Github for the latest CLI binary each time tailwind:build is executed. When actively developing and trying things out while building manually (without running with --watch, executing the command), a user may quickly exceed the maximum of 60reqs per hour to the Github API. This unnecessarily disallows offline development as well.

Workaround A simple workaround is to set the binary version manually, as this skips the check of the latest binary, eg.

symfonycasts_tailwind:
    binary_version: 'v3.4.0'

However, a user may want to not set this value, to ensure that the binary is updated as soon as possible.

Possible fixes There are multiple options to fix this and multiple of these solutions could be implemented together. Here, I'm listing some ideas.

  1. An option would be allowing the user to make authenticated requests in the same manner as Composer does, increasing the maximum to 5000reqs per hour.
  2. Another option would be to cache the latest version string.
  3. Another option would be to simply use any available binary when a 4/5 response is returned.
  4. Another option would be to load the full Tailwind css from PlayCDN during development (see #42 ). This has downsides though: it wouldn't allow for offline development, and it wouldn't help if any custom configuration of Tailwind was used.
bocharsky-bw commented 10 months ago

Hm yeah, caching the version for a short period of time (probably max up to 1h is would fix this issue). But not sure how it would be better to do it, add a required cache dependency? :/ Go with something custom, like storing the latest version in a temporary file?

Also, using any available bin sounds reasonable too, it's already downloaded anyway, so why not use it if exists when 4xx/5xx occur, this will fix not only rate limit problem but offline problem as well which is cool.

About authenticated requests - that seems an overkill in this specific situation IMO, it just feels like we're trying to ignore the problem of frequent requests with a hack.

weaverryan commented 9 months ago

Hm yeah, caching the version for a short period of time (probably max up to 1h is would fix this issue). But not sure how it would be better to do it, add a required cache dependency

That seems fine to me. The user will have the cache component already in practice, so adding it as a dependency would not be a big deal. I would cache the version that was found. Then, I would always make an API request. But if it fails, fallback to trying to look for the version in cache. PR welcome!