Rename custom scripts for `plugin-add` and `plugin-remove` phases in plugins to make clear when they are executed:
`plugin-add` -> `post-plugin-add`
`plugin-remove` -> `pre-plugin-remove`
Add a zsh-native completion system function for `asdf`.
I too often hit snags with bash completions in zsh, so I bias strongly
towards zsh-native completions.
This needs to end up in `$fpath` with a filename of `_asdf` but it
seemed unfriendly to use that name in this repo, so call it `_asdf.zsh`
and document a symlink. Mark the file as executable to be compatible
with one convention of "personal functions should only autoload if
executable" (but that's probably so historic that very few people still
use it; I'm one of them, though).
It's possible for plugins to define new asdf commands. This way plugins can extend asdf capabilities or expose utilities related to their managed tool.
For example, a `foo` plugin might expose the command `asdf foo bar` by providing an executable file at `bin/bar`.
If `bin/bar` is a file but has no executable bit set, then its considered a source-able bash script, and will be sourced
with all the functions in `$ASDF_DIR/lib/utils.sh` already loaded.
A good example of this feature is the `nodejs` plugin, where people must import the release team keyring before
installing a nodejs version. People can execute the following command without having to know where exactly is the plugin located.
Many users might want not to use shims and would prefer the asdf environment be automatically set for them when entering the project directory. Add a link to asdf-direnv plugin README for more details on how to integrate asdf with direnv to achieve this.
The recommended Homebrew setup required adding two `brew --prefix` commands
to the shell profile. `brew` commands canbe slow, so this introduced a notable
lag when sourcing the shell profile.
Homebrew paths do not change, so we can determine the necessary paths one time
during setup and use static paths in the shell profile.
* Add extra plugin dependencies
I found on a fresh Ubuntu install test that it pays to have unzip and curl installed for some of the asdf plugins to install properly so it seems to make sense adding these here to give a nicer getting started experience.
I do not have brew or spack handy to test but from what I can see these packages should exist.
* Update core-manage-asdf-vm.md
rename docs/homepage.md to docs/README.md as the Docsify default of loading README.md works in a multi-lang setup whereas defining a custom homepage does not at this time.
# Summary
The homepage wasn't importing the required `.md` files appropriately due to the Docsify embed feature requiring single quotes, not double quotes.
## Other Information
We should update the information about Prettier use to specify that these pages require single quotes.
* save old readme for migration purposes
* promote new readme
* use the repo readme from the doc site homepage
* mention extendable plugin system in title and old plugin support
* improve subtitles english
* update links to direct users to the site!
* add link to docs site in readme until github repo site link is populated
* update troublesome contributing section
# Summary
This contains fixes and significant improvements to the documentation site.
* fixes some routing issues due to erroneous docsify config
* fixed links and layout of 404 pg
* improved the language on the landing page as per #438
* propose a NEW_README.md tackling concerns with #438 and #422
* use docsify specific md to emphasise some text
* add docsify-themeable plugin to improve loading experience and future proof for customisation
* improve use of `asdf-vm` over `asdf`
## Other Information
Included in this PR is a file `docs/NEW_README.md` which is my proposed README for this repo. The intention was to have all documentation in a single place, the site, and simplify the readme bringing the focus to explaining the tool rather than instructing users on how to use it.
I will create a separate PR for the README, but in the meantime the landing page composes this new readme with the ballad.
* init docsify
* add config & plugins to support required features
* create cover page
* add sidebar headings
* add novel 404 page
* add translation message to 404
* add navbar with translations dropdown
* fix punctuation
* add all-plugins section pulling from asdf-plugins repo readme
* update sidebar with sections, better names & descriptions for contributors
* add changelog. pulls from repo
* add thanks page. credits, maintainers & link to contributors on github
* add core documentation
* rm old readme from docs/ folder
this was copied here on docsify init
* comment out some translation config
ideally this will remain commented out serving as an example for any translation contributions
* run prettier over markdown
* add plugins-create section
* add contributing sections to the docs
* fix cover page get-started link
* use the readme as the main homepage
* update asdf version in docs with release script
Many plugins were having this problem where they rely on accessing
GitHub's API for listing versions from some repo releases. But not
setting an Authorization token for `curl`, causes the test to fail.
We now detect that if the plugin `list-all` looks like accessing
`api.github.com` and if so, we also try to guess if the Authroization
header will be set. If not, we fail the test and head the plugin author
to some documentation on how to add it.
Hope this reduces the number of failures due to GitHub API rate
limiting on travis.
This feature allows the plugin to optionally change the executable path
of a shim prior to execution. This is useful when the plugin tool has
commands that may exist in multiple locations (like npm).
