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
output directory should be relative to the config file (when used) just like input is.
Motivation
I'm evaluating using this tool in a large monorepo where we would ideally extract i18n tags for each project independently, and due to how we need our files to work in git, it would co-locate the i18n files.
Currently, I was imagining putting a i18next-parser.config.js at each package root, and in CI having it just run each of those against the ci.
It makes sense that input is local to the config, as this allows each package to specify it's processed files. But they lose control over where their files go currently. In my singular CI setup, either the CI tool would need to put them all in one place, or it'd have to figure out the dir for each config and manually set the output path.
I think there are two different styles:
Co-locate output (described here)
Glob all inputs into a root dir
As a bonus, we could maintain functionality for both use cases (and enable more flexible usage) by adding a $CWD variable too. Config files could specify this to namespace themselves relative to where the script was run too.
🚀 Feature Proposal
output
directory should be relative to the config file (when used) just likeinput
is.Motivation
I'm evaluating using this tool in a large monorepo where we would ideally extract i18n tags for each project independently, and due to how we need our files to work in git, it would co-locate the i18n files.
Currently, I was imagining putting a
i18next-parser.config.js
at each package root, and in CI having it just run each of those against the ci.It makes sense that input is local to the config, as this allows each package to specify it's processed files. But they lose control over where their files go currently. In my singular CI setup, either the CI tool would need to put them all in one place, or it'd have to figure out the dir for each config and manually set the output path.
I think there are two different styles:
As a bonus, we could maintain functionality for both use cases (and enable more flexible usage) by adding a
$CWD
variable too. Config files could specify this to namespace themselves relative to where the script was run too.Example
output: '$CWD/locales/myspecialpackage/$LOCALE/$NAMESPACE.json'
The text was updated successfully, but these errors were encountered: