hak33m16 / gradle-properties-manager Goto Github PK

add jest and at least one passing test

build, run tests, run for prs and on merge to master

Method: https://docs.oracle.com/javase/7/docs/api/java/util/Properties.html#load(java.io.Reader)

Currently, we only support a very small subset of the spec outlined in the docs here. For a 1.0 release, I'd expect us to support the full spec in order to allow users to migrate any .properties files following it over to gpm

A nice utility feature we could provide on top of this:

• warn users if they're using an unrecognized escape sequence, since this is almost always an error, and they intend to escape the backslash itself instead

The method does not treat a backslash character, \, before a non-valid escape character as an error; the backslash is silently dropped. For example, in a Java string the sequence "\z" would cause a compile time error. In contrast, this method silently drops the backslash. Therefore, this method treats the two character sequence "\b" as equivalent to the single character 'b'. 

gpm init should fail if ~/.gradle directory is not found.

The npm run clean command could take a flag and prompt once to remove all gpm created file and directories.

Figure out how to get subcommands working for property and profile: https://github.com/tj/commander.js/#stand-alone-executable-subcommands

• Currently, you have to explicitly run gpm init before you can use the CLI. Since we're already having to check whether we're initialized or not, when any gpm command is run for the first time, we should prompt for initialization
• Since people may be prompted unexpectedly when trying to use gpm for the first time, we should revamp the initialization function to be more robust, and account for seamlessly guiding users out of a state where gpm may be partially initialized

It might be useful/make people more comfortable using the CLI if our dependencies have an SBOM created for vulnerability scans, using something like: https://www.npmjs.com/package/@cyclonedx/bom

Currently, in order to use gpman, you must always specify gpman property or gpman profile before performing CRUD operations on a property/profile. Instead, we could improve gpman interaction by assuming users will want to operate on properties rather than profiles, since this is a much more common use case. This could give us a new command layout that'd look something like:

gpman set <property name>
gpman unset <property name>
gpman ls

gpman profile # lists current profile
gpman profile set <profile name>
gpman profile create <profile name>
gpman profile delete <profile name>
gpman profile ls

Whatever changes are made, it'd be nice to have better documentation in the README (currently it's just the output of the auto-created --help info commander gives us). Maybe a walkthrough section of managing multiple profiles with gpman with nice animations similar to this: https://github.com/romkatv/powerlevel10k#configuration-wizard (although honestly these frustrate the hell out of me because they don't pause, so even just pictures would be fine)

This could definitely relate to/be done in tandem with #16

@Owlexandeer does this accurately capture the recommendations you were making?

Currently, line endings are all in Windows format (\r\n) since we develop on Windows machines (rather than just \n). However, after a WSL 2 upgrade, CLI utilities seem to fail to recognize the Node shebang we include at the start of our bin/ files (for gpm gpm property and gpm profile) which results in the following error if you attempt to run any of the gpm commands:

/usr/bin/env: ‘node\r’: No such file or directory

convert current code into typescript

add eslint/prettier, lint/format existing files