Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
added functional component example to simulate doc #2248
@ljharb i try to update the gh-pages docs by running the
can you publish the docs?
the command looks also very hacky for me and the empty commit at the begin of the command chain should be the problem.
is there a reason why you overwrite the gh-pages branch history? if it is only because of
@paulvollmer the published docs are only changed during a release of
The improvement I'd like to make to docs publishing is that each version's docs should be persistent - ie, what i'd like is each enzyme release to generate a new commit on top of gh-pages, that adds both a v1.2.3 directory, and updates the root to be the latest version, without altering previous versions. If that's something you're interested in, I'd be very happy to review that PR.
@ljharb okay, i got it.
the docs versioning task is interesting. for me it sounds like having the solution to surf the docs for a specific version.
maybe it make sense to add a select ui to choose which enzyme version you want to surf.
i think it is easy to refactor the script to build and publish to a directory of the name of the latest version. the challenge could be to generate the docs for the past versions. or did enzyme ever used the same docs build process?
That's my thought - that it would default to the latest, but there'd be a dropdown in the corner to switch between versions.
It would be fine to make "fill in the past version" be a one-off script that's only ran once (with the latest build process), to backfill - once it's in place, moving forward, the build script would just have to generate the new version.