Bashly 2.0.0 is in development

[DannyBen]

The first release candidate for Bashly 2.0.0 is now available:

gem install bashly --pre

The main change in 2.0.0 is a new completion system. Runtime completions are now generated natively as part of your Bashly script, with support for commands, arguments, flags, aliases, static and dynamic candidates, and file and directory completion. Shell wrappers are available for Bash and Zsh.

The PR with some more technical details is here: #721

This replaces the previous Completely-based implementation and keeps the completion definition alongside the rest of the CLI configuration.

The documentation for the development version is available here:
https://2-0-0.bashly-book.pages.dev/

If you are upgrading an existing project, see the migration guide:
https://2-0-0.bashly-book.pages.dev/upgrading-to-bashly-2.0/

This release candidate is intended to expose the new behavior to real Bashly projects before 2.0.0 is finalized. Reports about successful upgrades are useful too—not only bug reports—especially for projects with non-trivial command trees or completion requirements.

This discussion can also serve as a place to examine any aspect of the 2.0 changes, including behavior that feels unclear or could be improved.

Finally, this is the practical window for considering changes that would not fit comfortably into a backward-compatible release. If there is a feature or design change that previously seemed unsuitable because it would require breaking compatibility, it is worth raising now while 2.0.0 is still in development.

[meleu]

problem: command source files are implicitly wrapped by a function

UPDATE

discussion moved to #729

I have a pet peeve with the way we need to deal with the "command source files".

I'm talking about the fact that we're handling code that will be wrapped by a function and this fact is not explicit.

Two bad things results from this:

1. This is a cognitive load. Something the developer needs to remember. I'm already used to it but when I'm onboarding a new contributor I need to explain this detail.
2. This confuses the linter.

example

In a previous conversation @DannyBen mentioned:

you should not shellcheck the partial snippets, but just the final script.

Some points about this:

• I really enjoy having a linter right into the editor, highlighting issues exactly where they are, in a way where I can quickly handle them.
  • Also, my colleagues are not bash nerds like me. So having shellcheck in their editors is really useful for them, as a learning tool
• If I only shellcheck the final script, I need to configure pre-commit git-hooks/CI validation and spend human resources in the PR process

So... What I always end up doing is tweaking a .shellcheckrc and some # shellcheck disable=XXX here and there in order to still use shellcheck in bashly partials.

proposed solution

Note: I'm not taking into consideration the challenge of actually implementing it, just sharing what I think would be ideal as a bashly user.

A "command source file" should explicitly have a function. The name can be as the same pattern it has today: <app>_<subcommand>_command.

What I see as ideal is bashly build automatically validating if the file has a function with the right name.

[DannyBen]

1. I understand the use case.
2. I can see the value
3. Personally, I do not like it and don't want it in my own scripts.
4. For me it is a needless fragile and volatile repetition.
5. The function name is bashly-controlled, not user controlled.
6. If this is going to be implemented, I think it will be done in a backwards compatible and opt-in manner.
7. If we implement it, we can do it either explicit opt in (settings) or implicit (if command partial starts with a function, don't re-wrap it).
8. There is currently no mechanism in bashly that checks your bash code, and I don't think we need to start adding such checks - so this means that if this feature is added, the user is responsible for ensuring the proper function name.
9. I am open to it, I am not thrilled by it.

[DannyBen]

@meleu - can you open an issue (not discussion) with this? as it seems to be a viable feature candidate, I want to discuss it freely and separately, and get more opinions perhaps.

[meleu]

discussion moved to #729