YAML support

[Zyles]

Could you add YAML support?

The syntax is so much cleaner than JSON.

Thanks.

[s00d]

I'm not sure I'll work on this; it will take too much time. You can try doing it yourself.

[Buzut]

If I can add my 2 cents: on one hand, yes YAML could be convenient. On the other hand, YAML is extremely slow compared to JSON.

So although very convenient, I think the goal of this lib is to be simple & fast. If @s00d were to slowly implement all the features that make the official Nuxt i18n bloated, well, we'll end up with 2 bloated libraries I'm afraid…

[Hossein-Mirazimi]

I like to implement this feature
I watched your repository and I like it and I want to this feature on it

[s00d]

I like to implement this feature I watched your repository and I like it and I want to this feature on it

Hello, at the moment, I don’t see any fundamental need to support YAML in my library. There is no asynchronous loading in my library, and you can easily add support for any formats directly in the hook. For example:

import fs from 'fs';
import path from 'path';
import yaml from 'js-yaml';

export default {
  hooks: {
    'nitro:build:before': () => {
      const yamlsDir = path.resolve('yamls'); // Directory containing YAML files
      const localesDir = path.resolve('locales'); // Directory to save JSON files

      // Function to recursively create directories if they don't exist
      function ensureDirSync(dirPath) {
        if (!fs.existsSync(dirPath)) {
          ensureDirSync(path.dirname(dirPath)); // Recursively create parent directories
          fs.mkdirSync(dirPath); // Create the current directory
        }
      }

      // Function to recursively traverse the directory and convert YAML to JSON
      function convertYamlToJson(dir) {
        const files = fs.readdirSync(dir);

        files.forEach((file) => {
          const filePath = path.join(dir, file);
          const stat = fs.statSync(filePath);

          if (stat.isDirectory()) {
            // If it's a directory, recursively traverse it
            convertYamlToJson(filePath);
          } else if (path.extname(file) === '.yaml' || path.extname(file) === '.yml') {
            // If it's a YAML file, convert it to JSON
            const yamlContent = fs.readFileSync(filePath, 'utf8');
            const jsonContent = yaml.load(yamlContent);

            // Create the corresponding path in the locales directory
            const relativePath = path.relative(yamlsDir, dir);
            const localesFilePath = path.join(localesDir, relativePath, file.replace(/\.ya?ml$/, '.json'));

            // Create the directory if it doesn't exist
            ensureDirSync(path.dirname(localesFilePath));

            // Write the JSON file
            fs.writeFileSync(localesFilePath, JSON.stringify(jsonContent, null, 2));
            console.log(`Converted: ${filePath} -> ${localesFilePath}`);
          }
        });
      }

      // Start the conversion process
      convertYamlToJson(yamlsDir);
    },
  },
};

If I can add my 2 cents: on one hand, yes YAML could be convenient. On the other hand, YAML is extremely slow compared to JSON.

So although very convenient, I think the goal of this lib is to be simple & fast. If @s00d were to slowly implement all the features that make the official Nuxt i18n bloated, well, we'll end up with 2 bloated libraries I'm afraid…

Everyone wants a copy of i18n, but faster. I'm trying to at least maintain some level of performance.

[Hossein-Mirazimi]

thank you for your response! I believe we can incorporate this functionality into the module without adding any overhead. If the user selects YAML in module configuration, the functionality would apply only in that case. This approach ensures there is no impact on bundle size or performance for users who do not require YAML support.

[Buzut]

@Hossein-Mirazimi What's your use-case to favour YAML over JSON out of curiosity?

I find that the drawback of JSON is when you need multi-line content. In these cases, I found out that leveraging locale defineI18nRoute works very well with template literals!

[Zyles]

If I can add my 2 cents: on one hand, yes YAML could be convenient. On the other hand, YAML is extremely slow compared to JSON.

So although very convenient, I think the goal of this lib is to be simple & fast. If @s00d were to slowly implement all the features that make the official Nuxt i18n bloated, well, we'll end up with 2 bloated libraries I'm afraid…

I build my site to be static. If the site generates in 3 seconds vs 10 seconds it does not matter at all to me. Hell I don't even care if it takes 1 minute longer.

It's up to the user on what to choose for their need, if you want performance in a runtime environment choose JSON. More options is good.

[Zyles]

thank you for your response! I believe we can incorporate this functionality into the module without adding any overhead. If the user selects YAML in module configuration, the functionality would apply only in that case. This approach ensures there is no impact on bundle size or performance for users who do not require YAML support.

Exactly. Make it an optional dependency. If you need YAML support you install a second package like js-yaml. Then it is just a matter of doing an if statement when importing the files based on file extension.

js-yaml doesn't have to be installed by default.

[Zyles]

I have a solution for this using nitro:init with optional dependency. It only runs on start so there is really no runtime performance hit. But I am having problems with pnpm, so can't really commit the code. I don't usually use pnpm.

I get the following error:

$ pnpm run prepack
...
ℹ Stubbing nuxt-i18n-micro                                                                                  17:15:06
ℹ Cleaning dist directory: ./dist                                                                           17:15:06
✔ Types generated in .nuxt                                                                             nuxi 17:15:12
ℹ Building nuxt-i18n-micro                                                                                  17:15:14
ℹ Cleaning dist directory: ./dist                                                                           17:15:14

[17:15:31]  ERROR  Unexpected token (3:12) in M:\fork\nuxt-i18n-micro\node_modules\.pnpm\vue-router@4.5.0_vue@3.5.13_typescript@5.6.3_\node_modules\vue-router\dist\vue-router.d.ts

There are a lot of deprecated dependencies so should probably upgrade the package.

I tried updating all of them but then I get the error:

ℹ Stubbing nuxt-i18n-micro                                                                                  17:19:50
ℹ Cleaning dist directory: ./dist                                                                           17:19:50
✔ Types generated in .nuxt                                                                             nuxi 17:19:56
ℹ Building nuxt-i18n-micro                                                                                  17:19:59
ℹ Cleaning dist directory: ./dist                                                                           17:19:59
.nuxt/components.plugin.mjs(3,1): error TS2742: The inferred type of 'default' cannot be named without a reference to '~/node_modules/nuxt/dist/app/nuxt.js'. This is likely not portable. A type annotation is necessary.

Seems to be dependency problems.

[Zyles]

Please check my proposal and test it.

[Hossein-Mirazimi]

@Hossein-Mirazimi What's your use-case to favour YAML over JSON out of curiosity?

I find that the drawback of JSON is when you need multi-line content. In these cases, I found out that leveraging locale defineI18nRoute works very well with template literals!

Thanks for asking! I don’t have a particular use case for preferring YAML over JSON. I just thought it could be a helpful feature for other developers who might find it useful. 😊

[ManUtopiK]

I've not tested with nuxt-i18n-micro, but you may use the vite plugin @modyfi/vite-plugin-yaml to transform your yaml schema to json at build time. This is just a suggestion...