Error: Cannot find module './langs/cy.json'

[fsproru]

Getting the above error in Lambda. Happens on the initial load. Looking at the code, it's just cy happens to be the first element in the array of supported languages which gets loaded in entry-node.js.

Is there a way to specify only the language we need so we don't have to bundle all the available json language files into the lambda?

[bvanderdrift]

I received this error in Lambda while only needing the import

import {getSupportedLanguages} from 'i18n-iso-countries';

I realise it's a case-specific workaround but for anyone with this edge case you can also

import supportedLocales from 'i18n-iso-countries/supportedLocales.json';

[michaelwittig]

Hi @fsproru I must have missed your initial message here. What I understand is this:

We set entry-node.js as main in package.json which defines what is loaded when the module is loaded in a Node.js environment (not browser). If I get you right, you remove files from the langs folder to save some space. If you also modify the supportedLocales.json file accordingly things should work.

[bvanderdrift]

Hi @michaelwittig. I can't speak for @fsproru but I had the same error with a clean install of the packages, no changes to the langs folder. This was in an AWS Lambda environment with Node 14.x.x.

[michaelwittig]

@bvanderdrift I see. Not sure why I thought that files have been removed from the langs folder. How do you deploy your Lambda function? Any framework like SAM, Serverless Framework, ...

[bvanderdrift]

@michaelwittig we use Serverless indeed. I've done some digging before I found my own workaround but couldn't find any history of Serverless deleting/omitting certain files types/folders which might've accidentally deleted the files in the langs folder. There must be something funky going on though.

[michaelwittig]

@bvanderdrift I see. It would be interesting to see if the langs/*.json files are in the artifact that serverless creates and uploads to S3.

[bvanderdrift]

@michaelwittig I went into the deployed server, and found that all code (including npm packages) seems to have been included into a single minified file. My

import supportedLocales from 'i18n-iso-countries/supportedLocales.json';

statement seems to have been imported successfully, so the fact that the langs files are jsons shouldn't be the problem.

I wonder if this is because the require statements run inside a loop instead of in the root of entry-node.js and thus Serverless has not parsed those statements. If that would be the case this should be a wider-spread problem in Serverless.

I'm at my work on a tight deadline right now and sadly don't have the time to reverse our deployment to an errornous state and report what the deployed code looks like. Maybe someone could create a minified reproducible project in AWS Lamda using Serverless?

[michaelwittig]

this could be related to #212

[simon-neusoft]

I wonder if this is because the require statements run inside a loop instead of in the root of entry-node.js and thus Serverless has not parsed those statements. If that would be the case this should be a wider-spread problem in Serverless.

I don't know any bundler (e.g. webpack, esbuild) that supports dynamic require like in this case with a for loop.

We are still using 7.1 which has all requires statically. So pre #268. Issue #212 has a similar result as a bundler wouldn't handle fs.* calls.

Only solutions, if you want to support bundlers, I can currently think of is to either, just write all requires, use some sort of templating, or use a bundler for this project with its specific dynamic import syntax.

[leaumar]

Just adding for some readers: I'm getting the same error on lambda after deploying some typescript built with parcel 2.8.2 under yarn 3 with pnp. All we call is countries.alpha3ToAlpha2(country). Adding

import en from 'i18n-iso-countries/langs/en.json';
countries.registerLocale(en);

makes the json content show up in the output, but it still tries to resolve cy.json. Downgrading to 7.1.0 changed nothing.

Looking at the code, it's obvious entry-node.js is the problem as it tries to resolve all supported languages and register them. This file is loaded by dependency resolvers depending on bundling settings because of package.json:

  "main": "entry-node",
  "browser": "index",

I worked-around it rather cheaply by forcing our bundler to resolve the browser version instead of allowing it to choose from the exports...

import countries from 'i18n-iso-countries/index';

I now get a different error from a different lib (we're changing bundlers) so I can't verify it works when called yet, but the on-load error is gone.

[shellscape]

A much more matured solution to this would be:

• introduce a build script that created an imports.ts with static imports for bundler compatibility
• stop using an external d.ts file and author in TypeScript, allow tsc to create the type defs file
• run build script and then tsc, and then publish

We're trying to move past webpack and other bundlers are really struggling with the format of this package.

[shellscape]

For anyone still struggling with this package, I've published @shellscape/i18n-iso-countries and will endeavor to keep it up to date. The old node-entry.js file has been renamed to register-all.js and can be imported via @shellscape/i18n-iso-countries/lib/register-all