Closed djpowers closed 1 week ago
Thank you! Been waiting for this for my plugin that uses devdocs data.
When can we expect alias
to be live at https://documents.devdocs.io/docs.json or https://devdocs.io/docs.json? (not meant to be pushy, just to plan when the corresponding change can be implemented on my end.)
Awesome, thanks so much! I appreciate the refactoring improvement as well. It looks like the field is currently available from https://devdocs.io/docs/docs.json, however some aliases didn't seem to get mapped over. I see 11 results searching the JSON output for "alias": "
, while it looks like there are 33 defined aliases. I didn't see any sort of pattern regarding what was included/omitted at a quick glance.
I see 11 results searching the JSON output for "alias": ", while it looks like there are 33 defined aliases.
same here.
curl -sL "https://devdocs.io/docs.json" | grep "alias" | grep -v "null"
# → 12 aliases
curl -sL "https://documents.devdocs.io/docs.json" | grep "alias" | grep -v "null"
# → 0 aliases
This PR adds an "alias" key while generating https://documents.devdocs.io/docs.json, reusing the predefined aliases: https://github.com/freeCodeCamp/devdocs/blob/5c82069d893bc8dce505f421c6cf05135a593c33/assets/javascripts/models/entry.js#L20-L54
Sample output for one doc item looks like so:
This closes #2309, which provides more context on the rationale for this proposed change.
This implementation works, but could admittedly be more robust. I was hoping to avoid the aliases being defined in multiple places, and this seemed like the easiest approach to do so given we're working across JavaScript and Ruby.
Given that, if the team is open to this change, I'm happy to refactor if there's a preferred strategy. Thanks!