auto updating of main translation entries in Nx project does not work
julianpoemp opened this issue · 3 comments
I would like to use transloco-keys-manager in my angular projects. Each of the projects is a Nx mono repository. The problem: the auto-generation of translation entries doesn't work as expected: Only after a call of npm start
the translation files are updated, but not while development. I followed the instructions and installed the package as follows:
(I created a minimal project for easier reproduction of this issue: https://github.com/julianpoemp/nx-transloco-keys-manager)
nx add @ngneat/transloco
with defaults.nx g @ngneat/transloco:keys-manager
with option "both".- I changed the
webpack-dev.config.js
as follows:
const {TranslocoExtractKeysWebpackPlugin} = require('@ngneat/transloco-keys-manager');
module.exports = {
plugins: [new TranslocoExtractKeysWebpackPlugin({
rootTranslationsPath: "apps/nx-transloco-keys-manager/src/assets/i18n",
"add-missing-keys": true,
scopePathMap: {
general: "apps/nx-transloco-keys-manager/src/assets/i18n/general"
}
})]
};
- I changed the start script to
"start": "nx serve --extra-webpack-config webpack-dev.config.js",
because we're using Nx. - I replaced the app.component.html as follows:
<div *transloco="let t;">
{{t("general.test9")}}
{{t("test.test4")}}
{{t("test4")}}
{{t("test5")}}
{{t("test6")}}
{{t("test7")}}
</div>
- I changed
transloco-root-module.ts
as follows:
import { HttpClient } from '@angular/common/http';
import {
TRANSLOCO_LOADER,
Translation,
TranslocoLoader,
TRANSLOCO_CONFIG,
translocoConfig,
TranslocoModule, TRANSLOCO_SCOPE
} from '@ngneat/transloco';
import { Injectable, NgModule } from '@angular/core';
import { environment } from '../environments/environment';
@Injectable({ providedIn: 'root' })
export class TranslocoHttpLoader implements TranslocoLoader {
constructor(private http: HttpClient) {}
getTranslation(lang: string) {
return this.http.get<Translation>(`/assets/i18n/${lang}.json`);
}
}
@NgModule({
exports: [ TranslocoModule ],
providers: [
{
provide: TRANSLOCO_CONFIG,
useValue: translocoConfig({
availableLangs: ['en', 'es'],
defaultLang: 'en',
// Remove this option if your application doesn't support changing language in runtime.
reRenderOnLangChange: true,
prodMode: environment.production,
})
},
{ provide: TRANSLOCO_LOADER, useClass: TranslocoHttpLoader },
{ provide: TRANSLOCO_SCOPE,
useValue: "general"
},
]
})
export class TranslocoRootModule {}
- I run
npm start
and checked if "test" was added to en.json and es.json. Yes it worked. If I added moret()
calls to the html file whilenx serve
is still running, the new keys are not added during run time. Only right after runningnpm start
again. - Only the translation files that reference to the
general
scope are updated automatically.
Expected behaviour
As far as I understand, the "main" translation files (outside the scope) should be updated automatically, too.
How can I solve this?
I do not use nx, but it does not work for me, either. But if I change the file node_modules/@ngneat/transloco-keys-manager/webpack-plugin/generate-keys.js as following, new keys will be added to the translation files in the development time as well, no need to restart ng:
- after
generateKeys({translationPath:e,scopeToKeys:t,config:r}){
inserte = "/your/absolute/path/src/assets/i18n";
- instead of
${e}/${t?"":i}*.${r.fileFormat}
write${e}/${t?"":i+"/"}*.${r.fileFormat}
I will use this as a workaround till this issue is solved.
This actually isn't an Nx specific issue but rather a Windows one, the cause of which is here:
https://github.com/ngneat/transloco-keys-manager/blob/9affd8edebdf3520c9f499b73de88325d8ca7506/src/webpack-plugin/generate-keys.ts#L51-L54
The problem is that glob expressions must use POSIX paths, the reason being backslashes are escape characters in glob. When running on Windows, translationPath will be a Windows path with backslashes which all get escaped, resulting in a glob expression that matches nothing. As for a solution, you can enable windowsPathsNoEscape here if you understand its limitations.
@austinw-fineart thank you, but I had the problem on MacOS. I don't know if it's still an issue, I'll test it soon.