Release v0.12.0 - Internal refactor, lightweight parsing, and more
The latest release of JCLI has been released, featuring a decently large refactor
of core.d
which has allowed the creation of command parsing and command help text generating being split up into seperate
components.
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.
Changelog
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 -
CommandRawArg
has been renamedCommandRawListArg
, but there is analias
defined to keep current code working. - Feature - JCLI now provides an amalgamation of its and its dependency's source code.
- Feature -
CommandParser
has been added, which allows for the light-weight parsing of commands outside ofCommandLineInterface
. - Feature -
CommandHelpText
has been added, which allows for help text generation of commands outside ofCommandLineInterface
. - Feature - The
infogen
module has been created, which allows for introspection of commands outside ofCommandLineInterface
. - Change -
HelpTextBuilderSimple
no longer outputs empty sections. - Testing - The test runner now allows specific tests to fail, without the entire test run failing.
- Testing - The UFCS function
resultAssert
has been added to easily assert the state and value of aResult
.
Upcoming
For v0.13.0 my known concerns are to:
Split up bash completion into a sepearte
CommandAutoComplete
component, which can be used for purposes outside of bash completion. This also further shrinkscore.d
.Come up with an answer about whether I want to remove obsolete modules or not
Decide on whether to remove
jaster.cli.ansi
and 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.