Forge api failing with util.inherits is not a function

[aris]

hi there i started a confluence webtrigger template to fetch articles for the current customer but i’m getting these errors when i use

await api
    .asApp()
    .requestConfluence(route`/wiki/rest/api/space`);

[AlexeyKotlyarov]

Can you please show the complete code of the application, as well as package.json? Deploying a similar application that does Confluence calls didn’t trigger this error for me.

[aris]

its mostly from the crypto module
package.json

{
  "name": "scheduled-trigger",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "private": true,
  "dependencies": {
    "@forge/api": "^2.18.2"
  }
}

import * as crypto from "crypto";
export function generate_signature_hash(message) {
  return crypto
    .createHmac("sha256", Buffer.from(process.env.HMAC_KEY, "hex"))
    .update(message)
    .digest("hex");
}

[AlexeyKotlyarov]

Sorry, still can’t seem to reproduce.

• Are you using the latest Forge CLI version?
• You can get a better error message if you disable the function snapshotting and start a tunnel or deploy your function again. (But please don’t leave that on for production unless you need to.)

[belokurbohdan]

The same issue
Node version is not supported though (19.4.0)
Forge version 6.15.0

[belokurbohdan]

Hi @AlexeyKotlyarov!
After some investigation I found that the problem is with the new Forge version and crypto package.
I’ve tested my code with Forge 6.12.0 and my code works.

[AlexeyKotlyarov]

Unfortunately the crypto module isn’t supported in the current Forge runtime environment.

@belokurbohdan Are you working on the same application as @aris above? Would you mind showing a minimal reproducible example and how it works/doesn’t on different Forge CLI versions?

[tobitheo]

Okay, so I’ve been experiencing the same issue last week after I tried upgrading our @forge/cli package in our monorepo managed by yarn v1 (, I know). It only happened for our apps using UI Kit, pure Custom UI apps were not affected. (Turned out later @forge/api also has to be installed for me to be able to reproduce it)

So I came here and was hoping for a solution to pop up, but none did. So I dug in myself. And oh boy, did I ever dig a hole.

Solutions I found

For me, this issue could be fixed by doing either of these:

• running @forge/cli from its (via npm) globally installed location
• not using yarn to install packages
• haven’t tried this, but I would expect that using the Native Node.js Runtime EAP might fix this as well
• patching @forge/bundler like so (patch-package-compatible file @forge+bundler+4.10.3.patch)

diff --git a/node_modules/@forge/bundler/out/config/sandbox.js b/node_modules/@forge/bundler/out/config/sandbox.js
index 2d61c13..fac401f 100644
--- a/node_modules/@forge/bundler/out/config/sandbox.js
+++ b/node_modules/@forge/bundler/out/config/sandbox.js
@@ -39,7 +39,8 @@ const getCustomModulesAliases = () => {
         path: (0, common_1.resolveModulePath)('path-browserify'),
         querystring: (0, common_1.resolveModulePath)('querystring-browser'),
         stream: (0, common_1.resolveModulePath)('readable-stream'),
-        'supports-color': (0, common_1.resolveModulePath)('supports-color/index.js')
+        'supports-color': (0, common_1.resolveModulePath)('supports-color/index.js'),
+        inherits:  (0, common_1.resolveModulePath)('inherits/inherits_browser.js'),
     };
 };
 const getSandboxedRuntimeBuildConfig = (entrypoints, config) => {

But why does it happen?

Long story short, I looked at the generated bundles a lot and there’s a circular dependency between the polyfills for util and inherits. This fails in one case (bundle generated by locally installed @forge/cli) because that’s what circular dependencies do. In case of the bundle generated by the globally installed @forge/cli, there are somehow 2 versions of inherits which are imported just right so there is not really a circular dependency issue.

I have actually created a pretty long blog post in our company Confluence where I go into more detail which I can post here if anyone’s interested. But that’s the gist

A minimal reproducible example

I created resolutiongmbh/util-inherits-not-a-function-poc , which, following the instructions in the README, manages to reproduce the issue.

While reproducing this, I figured out

• @forge/api needs to be installed and used in the app as well
• yarn needs to be used

No idea why, but I presume npm might do some different magic with package resolution, while @forge/api not being present might not trigger the import? Not sure.

Why those solutions?

• Running the globally installed version of @forge/cli generated the bundle with 2 versions of inherits (among others). This is the case we’ve been investigating
• Why this doesn’t happen with npm? Not sure, see above. This might also just be the case in my environment
• Native Node.js Runtime EAP might fix this because no polyfills for util would be required since this is a native Node.js module
• Patching @forge/bundler to resolve the polyfill (browser version) directly would circumvent the circular import between util and inherits because the polyfill doesn’t try to import util in the first place

How could Atlassian fix this properly?

Add the patch to @forge/bundler’s sandbox.js file. That file already contains several patches that force Webpack to resolve the browser version directly, one more can’t hurt I’m sure.

I’ve opened a ticket about this: [FRGE-1254] - Ecosystem Jira . But I’m not sure this will be fixed because the native Node.js runtime will be coming soon anyway.

Footnotes:

[1] Why would I run @forge/cli from the dependencies in the first place? Three reasons:

• The linter run by the cli does not pick up my eslint config for some reason when I run the globally installed version so I get an error when it runs, but it works when I run it locally.
• I need to patch the CLI using patch-package to fix [FRGE-738] - Ecosystem Jira
• Same as why we don’t just install everything globally: I like to have control over the versions of dependencies used by

[AlexeyKotlyarov]

Thank you both @belokurbohdan and @tobitheo for the sample code! I’ve been able to reproduce the error. Will let you know how the fix goes.

[AlexeyKotlyarov]

Apologies for not updating the thread earlier - this has been fixed in the latest version of Forge CLI. I’ve closed FRGE-1254 as well.