Fix RangeError: Maximum Call Stack Size Exceeded in inspect-source.js with Hermes JS Engine in core-js versions 3.39.0

[RoshanSharma8245]

I'm encountering a RangeError: Maximum call stack size exceeded (native stack depth) error while using the Hermes JavaScript engine. The issue originates from inspect-source.js in core-js versions 3.39.0. The problematic code is as follows:

var functionToString = uncurryThis(Function.toString);

// this helper broken in `[email protected]`, so we can't use `shared` helper
if (!isCallable(store.inspectSource)) {
  store.inspectSource = function (it) {
    return functionToString(it);
  };
}

The error appears to stem from improper handling of recursion in store.inspectSource.
Proposed Solution:
Below is a suggested fix that resolves the issue by adding safeguards:

var functionToString = uncurryThis(Function.prototype.toString);

// Avoid recursion in `store.inspectSource`
if (!isCallable(store.inspectSource)) {
  store.inspectSource = function (it) {
    try {
      return isCallable(it) ? functionToString(it) : '';
    } catch (error) {
      // Fallback to an empty string if `functionToString` fails
      return '';
    }
  };
}

The changes include:

1. Correcting Function.toString to Function.prototype.toString.
2. Adding a try-catch block to prevent crashes in case functionToString fails.
3. Adding a fallback return value for non-callable inputs.

Please consider this fix to prevent similar issues in the future.

[irajdubey]

Facing the same issue.

[zloirock]

This logic was not changed in 3.39.0. It was not changed for a long time.

It's just a demetodized version of Function#toString.

It should throw an error for non-callable objects.

A RangeError here could show your problems with a transpiling - for example, you forget to exclude core-js in Babel / SWC settings.

Could you add a reproducible example?

[zloirock]

I don't run the full test case in Hermes, however I just run full core-js bundle with some simple test in Hermes and it works fine. So waiting for a reproducible example.

[zloirock]

Any news with a reproducible example?

[Vyazovoy]

This issue is likely caused by the same dynamic inline requires settings as was mentioned by #1237

[Vyazovoy]

I followed the @Titozzz recommendation but extended it to:

const path = require('path');
const fs = require('fs');

const coreJSInternalsDir = path.join(path.dirname(require.resolve('core-js')), 'internals');
const nonInlinedRequires = fs.readdirSync(coreJSInternalsDir, { withFileTypes: true }).filter((value) => {
  return value.isFile() && path.extname(value.name) === '.js'
}).flatMap((value) => {
  const name = path.join('internals', path.basename(value.name, '.js'));
  return [
    `./${name}`,
    `../${name}`,
    `../../${name}`,
    `../../../${name}`,
  ]
});
....

const config = {
  transformer: {
    getTransformOptions: async () => ({
      transform: {
        inlineRequires: true,
        // Fix for core-js cyclic dependency that lead to require stack exceeded error
        nonInlinedRequires: nonInlinedRequires,
      },
    }),
  },
};

[zloirock]

It seems @Vyazovoy is correct, it's an issue of your build process. Closed as can't reproduce. Please, add a reproducible example if you don't agree.