Release v0.12.0 - Internal refactor, lightweight parsing, and more
The latest release of JCLI has been released, featuring a decently large refactor
core.d which has allowed the creation of command parsing and command help text generating being split up into seperate
As a misc measurement of how large and overreaching it was/still is, Git reports that
core.d has lost 1,039 lines of code due to these changes,
slightly over half its original size.
And just as another misc measurement, with this release 33%LoC in JCLI are comments.
A slight warning: because of this large rewrite/split-up of
core.d, there might be undocumented breaking changes. Please file an issue
if they are fixable (look at me, pretending people actually use this library >x3).
I have hope though that with the new amalgamation file, it'll become much less of a hassle to use JCLI, because it should (barring bugs) just be a case of copy-pasting the file into your project, and then off you go.
Most changes are explained in the new README.
The following changes were implemented:
- Breaking - Inheritance for the foreseeable future is broken due to a language limitation.
- Semi-Breaking -
CommandRawArghas been renamed
CommandRawListArg, but there is an
aliasdefined to keep current code working.
- Feature - JCLI now provides an amalgamation of its and its dependency's source code.
- Feature -
CommandParserhas been added, which allows for the light-weight parsing of commands outside of
- Feature -
CommandHelpTexthas been added, which allows for help text generation of commands outside of
- Feature - The
infogenmodule has been created, which allows for introspection of commands outside of
- Change -
HelpTextBuilderSimpleno longer outputs empty sections.
- Testing - The test runner now allows specific tests to fail, without the entire test run failing.
- Testing - The UFCS function
resultAsserthas been added to easily assert the state and value of a
For v0.13.0 my known concerns are to:
Split up bash completion into a sepearte
CommandAutoCompletecomponent, which can be used for purposes outside of bash completion. This also further shrinks
Decide on whether to remove
jaster.cli.ansiand instead use JANSI. Depending on what I do with the utility modules I might just remove it altogether since I won't have need for it.
And of course, I'll be thinking of more stuff to add into this release as I go along.
I originally foresaw JCLI as being a complete CLI framework, but now I'm starting to wonder if I should go the path of seperate packages that compliment eachother.
For example, JCLI handles command parsing and binding; JANSI is used for the colourful output with maybe a different user I/O package built on top of it; another library built on top of JANSI that provides ANSI-enabled text components (e.g. tables), etc.
We'll just have to see what direction I want to go in. External thoughts are welcome as well.