mirror of
https://github.com/asdf-vm/asdf.git
synced 2024-11-15 01:28:17 -07:00
Update documentation
This commit is contained in:
parent
e968fe6142
commit
64d7cac9fd
25
CHANGELOG.md
25
CHANGELOG.md
@ -4,6 +4,17 @@
|
|||||||
|
|
||||||
Features
|
Features
|
||||||
|
|
||||||
|
* Subcommand CLI support.
|
||||||
|
|
||||||
|
Users familiar with sub-command aware tools like `git` can now
|
||||||
|
use `asdf` commands in the same way. For example:
|
||||||
|
|
||||||
|
`asdf plugin list all` is equivalent to `asdf plugin-list-all`
|
||||||
|
|
||||||
|
This is also the case for plugin extension commands, where the
|
||||||
|
plugin name is an asdf main subcommand. ie. Having a `foo` plugin
|
||||||
|
you can invoke: `asdf foo bar`
|
||||||
|
|
||||||
* Make `asdf plugin test` use the new `asdf latest` command. (#541)
|
* Make `asdf plugin test` use the new `asdf latest` command. (#541)
|
||||||
|
|
||||||
If a plugin version is not given explicitly, we use `asdf latest` to
|
If a plugin version is not given explicitly, we use `asdf latest` to
|
||||||
@ -16,18 +27,8 @@ Features
|
|||||||
|
|
||||||
* Add support for asdf extension commands.
|
* Add support for asdf extension commands.
|
||||||
|
|
||||||
When a plugin provides custom executables or bash-scripts under its `bin/` directory,
|
Plugins can provide `bin/command*` scripts or executables that will
|
||||||
it's now possible to invoke them with:
|
be callable using the asdf command line interface.
|
||||||
|
|
||||||
```shell
|
|
||||||
asdf nodejs import-release-team-keyring
|
|
||||||
|
|
||||||
# instead of people having to know where the executable is installed:
|
|
||||||
~/.asdf/plugins/nodejs/bin/import-release-team-keyring
|
|
||||||
```
|
|
||||||
|
|
||||||
As in nodejs case, plugin authors can use this feature to provide utilities,
|
|
||||||
or people can create plugins that are just extensions to asdf itself.
|
|
||||||
|
|
||||||
See `docs/plugins-create.md` for more info.
|
See `docs/plugins-create.md` for more info.
|
||||||
|
|
||||||
|
@ -88,22 +88,44 @@ Note: This will only apply for users who have enabled the `legacy_version_file`
|
|||||||
|
|
||||||
This can be used to further parse the legacy file found by asdf. If `parse-legacy-file` isn't implemented, asdf will simply cat the file to determine the version. The script will be passed the file path as its first argument.
|
This can be used to further parse the legacy file found by asdf. If `parse-legacy-file` isn't implemented, asdf will simply cat the file to determine the version. The script will be passed the file path as its first argument.
|
||||||
|
|
||||||
## asdf extension commands
|
## Extension commands for asdf CLI.
|
||||||
|
|
||||||
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.
|
It's possible for plugins to define new asdf commands by providing `bin/command*` scripts or executables that will
|
||||||
|
be callable using the asdf command line interface by using the plugin name as a subcommand.
|
||||||
|
|
||||||
For example, a `foo` plugin might expose the command `asdf foo bar` by providing an executable file at `bin/bar`.
|
For example, suppose a `foo` plugin has:
|
||||||
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.
|
|
||||||
The executable for `asdf foo` itself should be placed in `bin/default-command`
|
|
||||||
|
|
||||||
A good example of this feature is the `nodejs` plugin, where people must import the release team keyring before
|
```shell
|
||||||
installing a nodejs version. People can execute the following command without having to know where exactly is the plugin located.
|
foo/
|
||||||
|
bin/
|
||||||
```bash
|
command
|
||||||
asdf nodejs import-release-team-keyring
|
command-bat
|
||||||
|
command-bat-man
|
||||||
|
command-help
|
||||||
```
|
```
|
||||||
|
|
||||||
|
Users can now execute
|
||||||
|
|
||||||
|
```shell
|
||||||
|
$ asdf foo # same as running `$ASDF_DATA_DIR/plugins/foo/bin/command`
|
||||||
|
$ asdf foo bar # same as running `$ASDF_DATA_DIR/plugins/foo/bin/command bar`
|
||||||
|
$ asdf foo help # same as running `$ASDF_DATA_DIR/plugins/foo/bin/command-help`
|
||||||
|
$ asdf foo bat man # same as running `$ASDF_DATA_DIR/plugins/foo/bin/command-bat-man`
|
||||||
|
$ asdf foo bat baz # same as running `$ASDF_DATA_DIR/plugins/foo/bin/command-bat baz`
|
||||||
|
```
|
||||||
|
|
||||||
|
Plugin authors can use this feature to provide utilities related to their tools,
|
||||||
|
or even create plugins that are just new command extensions for asdf itself.
|
||||||
|
|
||||||
|
When `command*` files exists but have no executable bit set, they are considered to be
|
||||||
|
bash scripts and will be sourced having all the functions from `$ASDF_DIR/lib/utils.sh`
|
||||||
|
available. Also, the `$ASDF_CMD_FILE` resolves to the full path of the file being sourced.
|
||||||
|
If the executable bit is set, they are just executed and replace the asdf execution.
|
||||||
|
|
||||||
|
A good example of this feature is for plugins like `nodejs`, where people must import the release team keyring before
|
||||||
|
installing a nodejs version. Authors can provide a handy extension command for this without users
|
||||||
|
having to know where exactly is the plugin was installed.
|
||||||
|
|
||||||
If your plugin provides an asdf extension command, be sure to mention about it on your plugin's README.
|
If your plugin provides an asdf extension command, be sure to mention about it on your plugin's README.
|
||||||
|
|
||||||
## Custom shim templates
|
## Custom shim templates
|
||||||
|
Loading…
Reference in New Issue
Block a user