-
Notifications
You must be signed in to change notification settings - Fork 130
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
docs: put mapping in jsdoc #519
Comments
We should definitely do 4, and further I think we should drop the mapping concept altogether, and instead improve the search capability so it could look for metadata and not just function names so that searching for the lodash or ramda name would bring up the equivalent function. I think instead of @lodash and @ramda it would need to be a @mapping tag and we'd configure it to take a param and additional text so that it could be written as: * @mapping <library> [renamedName] [- additional context/differences/notes]
// Exact copy:
* @mapping lodash
// Renamed/changes:
* @mapping ramda cond - add `defaultCase()` as last case
// flexible to other libraries we can map to, Hack Standard Library, Python, Go, C, Java, etc...
* @mapping python zip - returns an array, not an iterator |
I'm now convinced that #708 is the better solution. Goodbye mappings! |
it'd be nice to have the mapping on the docs website; right now it's not mentioned
options:
index.astro
(aside: this has diverged from the repoREADME.md
; should that be changed?)mapping.md
to a file that we can indocs/src/data
, then read it formapping.astro
mapping.md
with a data file indocs/src/data
, then read it formapping.astro
@lodash
and@ramda
, then read existing jsdoc output formapping.astro
(and other options are possible too)
i personally like 4
The text was updated successfully, but these errors were encountered: