sync --remove-unused should respect push.namespaces

[gu-stav]

When running sync --remove-unused I believe there currently is no way to configure from which namespaces keys are removed. In our case we have an API (with an api NS) and a CSR app (NS app) and syncing either one of those apps leads to the loss of keys from a NS that is managed by that app.

I think --remove-unused either needs a way to pass in which namespaces it affects, or it should respect the namesspaces setting in push.namespaces which would imo be preferred.

.tolgeerc

{
  "defaultNamespace": "app",
  "patterns": ["./src/**/*.ts?(x)", "./src/**/*.vue"],
  "push": {
    "forceMode": "OVERRIDE",
    "namespaces": ["app", "shared"]
  }
}

I think the CLI has all information at hand already, because compare does not only list messages which are up for deletion, but also their namespace.

[stepan662]

Yes you are right, this is option is not currently available. However it was not intended to work this way and I'm not a fan of sharing of these options. The push and sync commands are quite a bit different.

I'm tagging this as enhancement, we can add this feature later.

[gu-stav]

I understand and thought so tbh. Thanks for the quick response.

Would you be willing to accept a PR for that? I could either explore the route using a CLI argument (which would probably the easiest) or introducing a new sync attribute on the config?

The former could probably look like and be in line with how pull works: --namespaces <namespaces...>.

tolgee sync --namespaces <namespaces...>

In case no namespaces have been passed the current behavior (all namespaces) could apply. This could work with with the config in a similar way than push.files does:

{
  "sync": {
    "namespaces": ["app", "shared"]
  }
}

However I am still a bit drawn to the idea of re-using push, because from my understanding sync is basically a composition of pull and push. Wondering if a new option key would make more sense to make this a backwards compatible.

Can't promise anything but if you are open to a PR I would look into it to get a feeling how much time I'd have to spent ✌🏼 Interested to hear your thoughts first.

[stepan662]

PR would be cool 🙂 I'm in favor having the option separately. The should be basically mapping the CLI options logic, so when it's a separate command, I would put it to separate section.