neeto-commons-frontend houses utility functions, components, hooks,configuration settings, etc. neeto-fields-nano manages dynamic fieldcomponents, while neeto-team-members-nano handles team member managementfunctionalities.

These nanos, along with others, reduce redundancy and promote consistencyacross our products.

Translation Challenges

Many of our packages export components with text that requires internalization,maintaining their own translation files. We encountered an issue with thewithT higher-order component (HOC) using react-i18next insideneeto-commons-frontend. Upon investigation, we found discrepancies in howpackages handled dependencies.

withT is an HOC which provides the t function from react-i18next to thewrapped component as a prop.

import { withTranslation } from "react-i18next";const withT = (Component, options, namespace = undefined) =>  withTranslation(namespace, options)(Component);export default withT;

// Example usage of withT:const ComponentWithTranslation = withT(({ t }) => <div>{t("some.key")}</div>);

Let us first understand the difference between dependencies andpeerDependencies. dependencies are external packages a library relies on,automatically installed with the library. peerDependencies suggest that usersshould explicitly install these dependencies in their application if they wantto use this library. If not installed, we will get warnings during installationof this library to prompt us to install the peer dependencies.

react-i18next and i18next were listed as peerDependencies inneeto-commons-frontend's package.json. So, it will be using the instances ofthese libraries from the host application.

Examining neeto-fields-nano, we found that it listed react-i18next andi18next as dependencies rather than peerDependencies. This meant it hadits own instances of these libraries, leading to initialization discrepancies.

Contrastingly, neeto-team-members-frontend listed react-i18next andi18next as peerDependencies, relying on the host application'sinitialization of these libraries.

The initialization logic, which is common among all the products, is placedinside neeto-commons-frontend. To ensure translations from all packages,including neeto-commons-frontend are merged with that of the host application,we crafted a custom initializeI18n function:

import DOMPurify from "dompurify";import i18n from "i18next";import { curry, mergeAll, mergeDeepLeft } from "ramda";import { initReactI18next } from "react-i18next";import commonsEn from "../translations/en.json";const packageNames = [  "neeto-molecules",  "neeto-integrations-frontend",  "neeto-team-members-frontend",  "neeto-tags-frontend",];const getPackageTranslations = (language, packageNames) => {  const loadTranslations = curry((language, packageName) => {    try {      return require(`../${packageName}/src/translations/${language}.json`);    } catch {      return {};    }  });  const allTranslations = packageNames.map(loadTranslations(language));  return mergeAll(allTranslations);};const packageEnTranslations = getPackageTranslations("en", packageNames);const en = mergeDeepLeft(commonsEn, packageEnTranslations);const initializeI18n = resources => {  i18n.use(initReactI18next).init({    resources: mergeDeepLeft(resources, { en: { translation: en } }),    lng: "en",    fallbackLng: "en",    interpolation: { escapeValue: false, skipOnVariables: false },  });};export default initializeI18n;

Here we are looping through all the packages mentioned in packageNames andmerging with the translation keys inside neeto-commons-frontend, along withthe translation keys from the host app are passed as an argument to initializeI18nfunction.

While this approach successfully merges translations, it introduced complexity.As our project expanded with the inclusion of more packages, we found the needto regularly update the neeto-commons-frontend code, manually adding newpackages to the packageNames array. This prompted us to seek an automatedsolution to streamline this process.

Given that all our packages are under the @bigbinary namespace in npm, weexplored the possibility of dynamically handling this. An initial thought was toiterate through packages under node_modules/@bigbinary and merge theirtranslation keys. However, executing this in the browser was not possible sincethe browser does not have access to its build environment's file system.

Enter babel-plugin-preval:

To automate our translation aggregation process, we turned tobabel-plugin-preval. Thisplugin allows us to execute dynamic tasks during build time.

babel-plugin-preval allows us to specify some code that runs in Node andwhatever we module.exports in there will be swapped.

Let us look at an example:

const x = preval`module.exports = 1`;

will be transpiled to:

const x = 1;

With preval.require, the following code:

const fileLastModifiedDate = preval.require("./get-last-modified-date");

will be transpiled to:

const fileLastModifiedDate = "2018-07-05";

Here is the content of get-last-modified-date.js:

module.exports = "2018-07-05";

Here, the 2018-07-05 date is read from the file and replaced in the code.

In order to use this plugin we just need to install it and add preval to theplugins array in .babelrc or .babel.config.js

Streamlining Translations with preval:

We revamped the initializeI18n function using preval.require to dynamicallyfetch translations from all @bigbinary-namespaced packages. This eliminatedthe need for manual updates in neeto-commons-frontend whenever a new packagewas added.

With preval, our initializeI18n function was refactored as follows:

const initializeI18n = hostTranslations => {  // eslint-disable-next-line no-undef  const packageTranslations = preval.require(    "../configs/scripts/getPkgTranslations.js"  );  const commonsTranslations = { en: { translation: commonsEn } };  const resources = [    hostTranslations,    commonsTranslations,    packageTranslations,  ].reduce(mergeDeepLeft);};

The code for getPackageTranslations.js:

const fs = require("fs");const path = require("path");const { mergeDeepLeft } = require("ramda");const packageDir = path.join(__dirname, "../../");const getPkgTransPath = pkg => {  const basePath = path.join(packageDir, pkg);  const transPath1 = path.join(basePath, "app/javascript/src/translations");  const transPath2 = path.join(basePath, "src/translations");  return fs.existsSync(transPath1) ? transPath1 : transPath2;};const packages = fs.readdirSync(packageDir);const loadTranslations = translationsDir => {  try {    const jsonFiles = fs      .readdirSync(translationsDir)      .filter(file => file.endsWith(".json"))      .map(file => path.join(translationsDir, file));    const translations = {};    jsonFiles.forEach(jsonFile => {      const content = fs.readFileSync(jsonFile, "utf8");      const basename = path.basename(jsonFile, ".json");      translations[basename] = { translation: JSON.parse(content) };    });    return translations;  } catch {    return {};  }};const packageTranslations = packages  .map(pkg => loadTranslations(getPkgTransPath(pkg)))  .reduce(mergeDeepLeft);module.exports = packageTranslations;

In this workflow, we iterate through all the packages to retrieve theirtranslation files and subsequently merge them. We are able to access thetranslation files of our packages since we have exposed those files in thepackage.json of all our packages.

files property in package.json is an allowlist of all files that should beincluded in an npm release.

Inside package.json of our nanos, we have added the translations folder to thefiles property:

{  // other properties  files: ["app/javascript/src/translations"];}

It's worth noting that we won't run preval at the time of bundlingneeto-commons-frontend. Our objective is to merge the translation keys of allinstalled dependencies of the host project with those of the host projectitself. Since neeto-commons-frontend is one of the dependencies of the hostprojects, executing preval within neeto-commons-frontend is not what weneeded.

Consequently, we've manually excluded the preval plugin from the Babelconfiguration specific to neeto-commons-frontend:

module.exports = function (api) {  const config = defaultConfigurations(api);  config.plugins = config.plugins.filter(plugin => plugin !== "preval");  config.sourceMaps = true;};

With this change, the Babel compiler simply skips the code for preval duringbuild time and the preval related code will be kept as it is after compilationfor neeto-commons-frontend.

Another challenge arises from the default behavior of webpack, which does nottranspile the node_modules folder by default. However, it's necessary for ourhost application to perform this transpilation. To address this, we wrote acustom rule for webpack. The webpack rules are also placed inneeto-commons-frontend and shared across all the products.

  {    test: /\.js$/,    include:      /node_modules\/@bigbinary\/neeto-commons-frontend\/initializers\/i18n/,    use: { loader: "babel-loader", options: { plugins: ["preval"] } },  },

This configuration ensures that Babel applies the necessary transformations tothe code located innode_modules/@bigbinary/neeto-commons-frontend/initializers/i18n/ within thehost application.

Upon transpilation, our system consolidates all translations from each package,including those from the neeto-commons-frontend package, and incorporates theminto the host application.

To mitigate potential conflicts arising from overlapping keys, we've implementeda namespacing strategy for translations originating from various packages. Thisensures that translations from our packages carry a distinctive key, uniquelyidentifying their source.

For example, consider the neeto-filters-nano package. In its Englishtranslation file (en.json), the translations are organized within a dedicatednamespace:

neetoFilters: {    "common": { }}

Conclusion:

Leveraging babel-plugin-preval significantly simplified our translationresource loading process. The automation introduced not only streamlined ourworkflow but also ensured that our applications stay consistent and easilyadaptable to future package additions.