Spaceship-prompt: line break for package version

[imjma]

Issue

line break for package version

Screenshot

Provide a screenshot that shows your issue

Environment

Spaceship version: 3.4.1 (use echo $SPACESHIP_VERSION)
Zsh version: 5.5.1
Zsh framework: antigen
Zsh plugin manager: antigen
Terminal emulator: iTerm/Alacritty
Operating system: macOS

Relevant .zshrc

# your configuration here

[nfischer]

@sthtodo I suspect that folder contains this package.json file. If that's true, it appears that both .version and .hexo.version are merged together for the package section (sounds like a bug).

As a workaround, you can disable that section with:

SPACESHIP_PACKAGE_SHOW=false

[salmanulfarzy]

This seems like rare case for me how often does cases like this arises ? Is it safe for us to assume the topmost result will correspond to the _actual_ package version ?

[nfischer]

Is it safe for us to assume the topmost result will correspond to the actual package version ?

The only "safe" way is to parse JSON. You'll have to decide if this has acceptable performance.

However, a (more performant) hack is probably acceptable for a shell prompt. If you (mainly) care about npm modules, you can just modify the regex to require 2 spaces of indentation.

You can try a more elaborate hack, but at some point, it's not worth the effort.

[Darkhogg]

I would personally favor correct JSON parsing using node -e 'console.log(require("./package.json").version)' or, if available, jq -r .version <package.json. Using node seems VERY slow in comparison to jq, 300ms vs 10ms on my machine, but the grep with spaces approach is hacky and can fail for packages with bad formatting or a different tab size.

[salmanulfarzy]

Performance between node and grep to get package version was previously compared at https://github.com/denysdovhan/spaceship-prompt/issues/171#issuecomment-315541526. As for jq, PR #441 is already modified to include jq (https://github.com/denysdovhan/spaceship-prompt/pull/441/commits/7b3c7e00ec0afb26b8c67f80e34f843f4ecaeba8)

[maximbaz]

The point is that grep is a hacky solution that doesn't work in 100% of cases, and I agree with this sentiment. If you don't want to use jq alone, it's better have jq + node than jq + grep.

[salmanulfarzy]

Until there are issues because of this hacky grep solution, I would prefer grep before node and consider performance to be more important.

[Darkhogg]

The grep solution is equivalent to parsing HTML using regex. I would recommend a the following ways of parsing the version, in order, from faster to slower, before even trying to use grep (time taken in my machine, an Arch Linux desktop):

• jq -r .version <package.json (0.007s)
• python -c "import json; print(json.load(open('package.json'))['version'])" (0.032s, works in both Python 2 and 3, a bit faster in python 2)
• node -e "console.log(require('./package.json').version)" (0.062s)

Those are all correct, and I'd say being correct is quite important.
Now to grep: The only you can do in the face of multiple version keys is to guess. No method will be correct 100% of the cases, but that's ok. Whatever method is used should only be used if none of jq, python and node are found, which is unlikely in any system, so a best effort is ok. I don't think performance should be a factor in deciding the method if the faster method is wrong. And if you want performance, just install jq.

[Darkhogg]

The package.json file is often used by libraries for their configuration, to aid in keeping everything at one place. This can make an extra version field inside such a configuration perfectly normal, even if a bit strange.

Note that we're not saying spaceship should rely on any external tool. These are solutions to the problem that can be added in the (extremely likely) case those tools are present, and the current behaviour can be a fallback. Even this fallback is not perfect though, but anybody interested in having a correct, non-hacky package version section can just install jq (which is pretty useful anyway).

[nfischer]

and the current behaviour can be a fallback

Agreed. I like jq as the preferred approach, with grep as the fallback. So I agree, let's take #441.

but anybody interested in having a correct, non-hacky package version section can just install jq

Yup, another good point in favor of #441. In the rare case of non-formatted JSON, users can immediately fix the problem by installing jq, with no loss in performance.