Hysen Labs
Library / SDK
s00d/nuxt-i18n-micro avatar
s00d

nuxt-i18n-micro

Nuxt I18n Micro is a fast, simple, and lightweight internationalization (i18n) module for Nuxt

247 stars28 forksTypeScriptMIT
DEEP OPEN-SOURCE ANALYSIS

Nuxt I18n Micro speeds up translations

Nuxt I18n Micro is a lightweight Nuxt module that cuts build time, memory, and bundle size versus the older nuxt-i18n.

Why it was built

Nuxt I18n Micro is a fast, simple, and lightweight internationalization module for Nuxt. The README says it was created to fix performance problems in the original nuxt-i18n module, especially in high traffic environments and projects with large translation files. The specific problems it lists are high memory consumption during build and runtime, slow performance with large translation files, a large bundle size, and known memory leaks and unpredictable behavior under heavy load. The Micro module is built from the ground up to be efficient, with the stated aims of minimizing build times, reducing server load, and shrinking bundle sizes. Even though it is compact, the README says it is designed with large projects in mind. The pitch is not that it has more features than the original, but that it stays small and fast where the original became heavy. For a team running a Nuxt site with many locales and big message catalogs, those differences show up directly as lower build cost and steadier response under load, which the project backs with its own benchmark suite. The decision to rebuild rather than patch the original suggests the author judged the old architecture as the root cause, so a clean implementation was the more honest path than incremental fixes that would still carry the same weight.

Measured against the original

The README includes a performance comparison run with the same fixture suite against @nuxtjs/i18n@10.6.0 on the same hardware, plus a plain Nuxt baseline that loads JSON with no i18n logic. The reported numbers show i18n-micro at about 5.34 seconds build time, 1.74 MB code bundle, and 1,065 MB peak memory, while @nuxtjs/i18n v10.6 came in at 8.34 seconds, 2.16 MB, and 1,821 MB. Under a stress test, i18n-micro served 275 requests per second in Artillery with 483 ms average response, against 143 requests per second and 956 ms for the original. The project is careful to note what counts as code bundle, excluding the translation payloads, because older tables that mixed message chunks into app code overstated the original's size. It also notes the plain Nuxt baseline exists only for measuring overhead. The conclusion the README draws is that Micro leads on build cost and especially under load. A full benchmark report link is given for methodology and charts, so the claims can be checked rather than taken on faith. The honesty about what counts as code is important, because it shows the author is not padding the comparison by counting message files as application weight, which would have made the win look larger than it is.

Routing and translation loading

The module handles locale prefixes through two small packages: @i18n-micro/route-strategy at build time and @i18n-micro/path-strategy at runtime, with strategies such as prefix, no_prefix, prefix_except_default, and prefix_and_default. Translation loading is kept simple: only JSON files are supported, split between a global file for common text like menus and page specific files that are auto generated in dev mode when missing. The core is described as a single Nuxt module plus a small set of runtime plugins, which is meant to keep it easy to understand, extend, and maintain. Installation is a single command, npm install nuxt-i18n-micro, followed by adding the module to nuxt.config.ts. The module is written in TypeScript and is released under the MIT license. For a Nuxt team evaluating a switch, the practical steps are short: install, register the module, point it at JSON translation files, and pick a routing strategy, then rely on the benchmarked gains in build and serving cost. The split between a build time strategy package and a runtime strategy package is a reasonable design, because route generation belongs at build while path resolution belongs in the running app, and keeping the two separate matches that split cleanly. Restricting translations to JSON also keeps the loading model easy to reason about, since there is one file format to validate and the dev mode auto generation means a new page gets its placeholder file without the developer creating it by hand before the first request.

Editorial conclusion

The module is released under the MIT license, written in TypeScript, and documented at s00d.github.io/nuxt-i18n-micro.

DEEP OPEN-SOURCE ANALYSIS

Official sources

Community notes

Community notes