It’s a useful thing to be able to deprecate a lot of terms only with CLI parameters, otherwise it applies on all upload and it could be problematic
Can you please elaborate on this a bit more?
You can apply deprecate on the file level, which should solve this.
What I understood from the doc is I have to specify the deprecate option from within the localazy.json
file. But I don’t want to deprecate all the time, on all my branchs. It would have been simplier if I could specify this with CLI args.
By file level what do you mean?
I see. This is not yet possible.
You could have two different localazy.json
files and switch them using the command line parameter -c
or you could have a script to first change the value in the file and then run localazy
command.
If you specify "deprecate": "file"
, you don’t need to be afraid of deprecating the rest of the project, but I understand that it’s not what you need when uploading files from different branches.
I didn’t think about the two different files. This is a nice approach
We have improved support for extra parameters, so it’s now possible to do it like this:
{
"upload": {
"deprecate": "${deprecate}"
}
}
with passing the argument to CLI: localazy upload -p deprecate:file
This feature is available in version 1.6.4. The full description is here:
It’s a super powerful feature you just released! But can you make deprecate
entry in localazy.json optional?
If I update my json with "deprecate": "{deprecate}"
I can’t have a falsy value by default. I have to choose between file
or project
only.
Do you have a way to achieve this?
I’m adding a new none
option to our list for a new iteration. Great idea!
At the moment, there are two workarounds you can use.
1. Pure CLI aka the super ugly one
Since extra parameters are evaluated before the JSON is parsed, you could write your configuration like this:
{
"upload": {
${deprecate}
"files": "translations/*.json"
// ...
}
}
And then invoke the command this way to enable the deprecated feature:
localazy upload -p 'deprecate:"deprecate":"file",'
Or without deprecation:
localazy upload -p 'deprecate:'
However, it breaks the JSON structure.
2. The scripting one
You can have your localazy.json
as usual and write a short script to add/remove the line using sed
, awk
or grep
to create a new localazy.temp.json
which will be used instead (and removed afterward).
E.g., something like this (for Linux) would be almost identical to localazy
command (including parameters, except for -c
) but would modify the localazy.json
and use it automatically.
#!/bin/bash
grep -v "deprecate" localazy.json > localazy.temp.json
command=$1
shift
localazy "$command" -c localazy.temp.json "$@"
rm localazy.temp.json
If you place it under something like /usr/bin/localazy-no-deprecate
, you can call it from anywhere on your system
Technically, this solution is more flexible than extra parameters, but it’s platform-dependent and hence the newly introduced feature.
A possible improvement for the super ugly one
The localazy.json
file like this will be fully valid JSON:
{
"upload": {
"${extraKey}": "${extraValue}",
"files": "translations/*.json"
// ...
}
}
And you can run the CLI with the deprecate feature enabled like this:
localazy upload -p extraKey:deprecate -p extraValue:file
And without the deprecation:
localazy upload -p extraKey:keySeparator -p extraValue:.
The second invocation just set keySeparator
to its default value and thus has no effect at all while providing a valid configuration.
One more update :-))
We made a mistake in the group evaluation, so with the fix, we also added the none option:
With configuration:
{
"upload": {
"deprecate": "${deprecate}"
}
}
it’s possible to call CLI to select the deprecation mode dynamically:
localazy upload -p deprecate:project
localazy upload -p deprecate:file
localazy upload -p deprecate:none