You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recent versions of trunk (definitely 0.21.1 but I've reproduced in 0.21.4) have started requiring the --release CLI parameter with a boolean argument (as --release=true). I suspect that's not intended: The commit message at 265599c#diff-46230eb6eb9a3792464a39b022f624c28ce91fed38482b30f47f483f7ef14967R24 states non-value variants are meant to be acceptable.
Reproducable with:
:; trunk build --release ./index.htmlerror: invalid value './index.html' for '--release [<RELEASE>]' [possible values: true, false]For more information, try '--help'.
Since the cmd.rs code didn't change, is a downstream dependency misbehaving?
The text was updated successfully, but these errors were encountered:
clap likely can't know if the index.html argument is for the --release flag or not since there is also an optional positional argument present.
For example trunk build --release ./index.html:
Is this a faulty argument for release, or are they seperate arguments (--release and ./index.html)?
The error itself is somewhat confusing though.
I am not sure this can be changed on trunk's end (though its been a while since I checked the CLI code) but as a practical solution you instead run trunk build ./index.html --release, and it will build it in the release profile. Simply putting the target argument before the flags should work since now there isn't ambiguity.
Edit: Tested with trunk 0.19.3, and trunk build --release ./index.html works fine so its definitely a regression.
Recent versions of trunk (definitely 0.21.1 but I've reproduced in 0.21.4) have started requiring the
--release
CLI parameter with a boolean argument (as--release=true
). I suspect that's not intended: The commit message at 265599c#diff-46230eb6eb9a3792464a39b022f624c28ce91fed38482b30f47f483f7ef14967R24 states non-value variants are meant to be acceptable.Reproducable with:
Since the cmd.rs code didn't change, is a downstream dependency misbehaving?
The text was updated successfully, but these errors were encountered: