-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Choose a new static-site generator #7982
Comments
Docusaurus is pretty great for mostly static sites - I'd recommend trying it out. It does let you embed React components too 😄
I don't think it's officially supported but you can use something like |
Thanks for replying 😁
Most of our content is generated at build time. So it's static from the perspective of the consumer, but not from the perspective of the Shields maintainer. Do you think Docusaurus is a good fit for that? react-snap looks interesting too. |
I've not used it, but I have heard good things about Docusaurus. It is something of a mindset shift from where we are now but there is something tempting about framing and thinking about the frontpage of shields.io as documentation. |
One thing we could do to try out Docusaurus is have a look at it for https://contributing.shields.io/ as a first step. Refs #4139 |
OK, so docusaurus is pretty cool and I've produced a proof-of-concept showing how we might use docusaurus for the main shields.io website:
The key concept here is: In shields, the URL schema is the API. At the moment, we use the data in the badge service files to make this file called
If you squint at this the right way, the contents of ..and that's pretty much what I've done. So as well as docusaurus I have also used https://github.com/cloud-annotations/docusaurus-openapi . This does 99% of what we need out of the box, but I did need to make a few modifications to it:
For the moment I've done this by defining a custom theme. Unfortunately, this requires duplicating a large chunk of the docusaurus-theme-openapi code beyond just the bits I wanted to customise. I don't really want to be relying on this as a long-term position. Assuming we want to move forward with this, one of my next jobs is to try and make some upstream contributions which make it easier to apply these customisations without having to hard-fork most of the theme. For the purposes of a proof-of-concept we can evaluate, the approach I've taken will do the job. Obviously this is not complete, but I think I've tried out a good enough selection of examples to conclude that this is a viable way forward for us. You can get a rough idea of what I have/haven't thought of from the commit history on the repo https://github.com/chris48s/shields-docusaurus-poc/commits/main I think the big upsides of this approach are:
The possible downsides are:
The things that are still unknown/untested are:
Obviously I've only gone so far with this proof of concept. I've only implemented a subset of features and there's a bunch of content/styling things we can work on further. I think what I'm mainly looking for at this stage is:
There are things about the proof-of-concept that could be better and extra things we could do, but are there any showstoppers ? I'd be particularly interested in getting some feedback from @paulmelnikow @calebcartwright @PaulaBarszcz , but anyone involved in this process: please feel free to chime in. |
TLDR: I like it. Great job, Chris :) Link to live Shields POC on Docusaurus by Chris: https://chris48s.github.io/shields-docusaurus-poc/
https://jestjs.io/search?q=mock Jest docs use Docusaurus. The search for 'mock' (probably the most popular word in Jest :D), had 224 results and was fast.
If this is a problem, we could limit the number of cases with optional param variants by moving them to query params. That way, e.g. Bitbucket/Github badges would be consistent with GitLab with its glorious repo/subrepo names containing slashes.
Before we move forward with a potential Shields migration to Docusaurus, it might be a good idea to open a few issues in docusaurus and/or docusaurus-openapi, with proposals regarding the most important changes needed by us. We'll see if they are fine with the proposed direction.
From my perspective this is a big benefit.
Maybe sth along these lines - https://docsearch.algolia.com/. It is neater and clashes less with the dark mode.
|
Thanks for taking the time to give the tyres a good old kick :) Some good points raised there. I'll try to follow up or reply to all that over the next few days but having given it a quick skim, I don't think there is anything there that completely blows the approach out of the water 🤞 |
I think I have covered replying to everything here one way or another, but not all in the original order 🙃
Jest isn't quite the right comparison point, but this is a useful prompt to explain this more clearly. There are multiple options for implemeting search in Docusaurus: https://docusaurus.io/docs/search Jest are using Algolia, which is a hosted service well suited to dealing with large search indexes. What I've used on the proof-of-concept is a local search plugin (I've used https://github.com/easyops-cn/docusaurus-search-local - there are others). These ship your entire search index to the user's browser and perform the search client-side. This is a simpler approach (and performant for small sites) but there is going to be an index size where you hit a tipping point and this stops being sensible. This is why I mention search performance/index size and why jest isn't an apples-for-apples comparison. That said, if we outgrow local search it looks like we would meet the criteria to get a free Algolia account. I think it is unlikely to be a showstopper, but I don't really know how big an index shields will generate until we try it with a realistic amount of content.
It is only docusaurus-openapi where I'd like to upstream some changes. Nothing to docusaurus core.
Kinda like this, I guess.. 😄 I think that is OK.
Yep. Good question. I didn't have an example showing it originally, but we can do this in OpenAPI using an enum. I've added another example to show what this looks like:
(have a look at the VCS Type param)
So this is good feedback confirming that this is not obvious and we'll need to explain better (you'll notice I've brushed over this in the proof of concept by making the docs for this "bla bla bla - explain the static badge here" :D because I knew this would be content that requires a bit of thought to write). This is probably the most difficult badge to explain in this format because (from an OpenAPI perspective) the static badge doesn't take multiple parameters, it takes a single parameter containing either the label, message and color separated by dashes, or the label only and a color separated by dashes. So a valid call would look like either: or I think the way to deal with this is probably going to be by including some examples of URLs/badges in the description on this page. I think having a dedicated page we can link to where we can write up some explanation of this and provide examples will still be a big improvement over what we have now, even if this is one of the harder endpoints to document.
Yeah we can link to https://stats.uptimerobot.com/PjXogHB5p like we do on https://shields.io/ - its a content design issue though. There are other bits like links out to external sites that we'll want but I've not bothered to reproduce it all completely.
Yep. We can embed any HTML in the description, so all that is tweak-able
Yep. I didn't do it for all of them, but if you look at https://chris48s.github.io/shields-docusaurus-poc/badges/localizely-overall-progress you can see an example of one where I've filled in examples for the params. When we come to generate the OpenAPI spec, we already have examples stored on the badge class we can consume.
Tbc. The proof-of-concept shows we can add arbitrary pages to the site and use HTML in badge descriptions (see https://chris48s.github.io/shields-docusaurus-poc/badges/localizely-overall-progress agsain) so I'm not worried about it at this stage. It will slot in somewhere.
Heh. This aint my first rodeo 🤠 . Having worked on open source projects that accept community translations before, there are several problems you run into:
I've only ever really seen this work when there is someone on the project core team who speaks the target language and is willing to commit to maintaining the translations over a long period of time, or if you have budget to pay for translations. In general, as well as looking to improve our website, one of the things I really want to try and achieve here is to also reduce the maintenance overhead of the site. In my experience, publishing a website in multiple langauges is a really good way to massively increase the maintenance burden.
So on the proof-of-concept site, you'll see that
Dunno. Tbh, I might drop this. The template site docusaurus spat out had a blog so I decided to roll with it in the proof of concept, but we can change it.. or ditch it completely. This is about content really. It shouldn't influence the tech choice. There is also some feedback about the content I put on https://chris48s.github.io/shields-docusaurus-poc/community Basically with this page, I just (mostly) re-created what we've got on https://shields.io/community as a starting point and I think most of the comments about this equally apply to https://shields.io/community . The feedback isn't invalid and I don't want to completely dismiss it, but again this is all about content/design. I don't think any of it really influences "should we move forward with docusaurus/docusaurus-openapi" so I'm not going to get too bogged down in it at this stage as that's what I'm really trying to evaluate at this stage. One thing I will quickly note though is that a lot of this is really feedback about the OpenCollective contributor images. I do fully agree that these are imperfect, but they do also allow us to show a logo/link for everyone that donates (even if some of them look sub-optimal) with zero maintenance overhead to update it over time (we can "set it and forget it"). This effort:functionality ratio is one thing they do have going for them 😄 |
Thanks for all your answers & explanations, @chris48s. |
I've gone a bit quiet on this one lately, but I have been working on some stuff upstream that I hope will help me get back to this again soon. |
Personally I'd like to keep the page even if we drop it from the nav menu (assuming it's not too much trouble). I feel like the one blog posted is worth trying to keep around in perpetuity even if only as an easter egg of sorts |
Update on this: I'm currently working on a script to chuck out an openapi spec for shields. Its currently a bit half-assed but I've got it to a stage where it can spit out a valid spec for about 500 endpoints with some bits missing. This is less than all of them but a lot closer to the finished product than the ~10 I tested with in the proof of concept so I decided to see how big a search index that would generate. That content generated a search index of just over 3Mb so my guess is we'll be looking at something in the ~4Mb ballpark all told. That is bigger than I'd like, but not completely outrageous. I've seen other docusaurus site using a local search backend with a larger index (up to about 10Mb) so I think I'm fairly happy to roll with local search, at least as a starting point. It is not a showstopper. |
Quick update on this:
The wheels continue to turn, slowly. |
We have just launched the new Docusaurus-based frontend https://shields.io/ There is more work to do, but I'm going to track follow up tasks in a series of more focussed issues |
Gatsby isn't the best fit for us. I think these are the key pain points (though other maintainers may describe them better!)
From #7978 (comment):
I think the ideal criteria are:
For single-page apps, I use Create React App, though it doesn't generate static pages. I've been meaning to check out Vite, which feels like a fresh look at the problem, though I think it may have the same limitation in the sense that static site generation is not what it does.
As a starting point I would suggest we evaluate these:
There are a few other static site generators for React listed here: https://jamstack.org/generators/
And… I'm curious if other folks might have ideas of options to consider here! (cc @Daniel15)
The text was updated successfully, but these errors were encountered: