How can I use Octokit in a CommonJS Firebase Functions environment without switching to ESM?

Below is an explanation and a couple of approaches you can try.

---

The Issue

Octokit (and particularly the @octokit/app package) is published as a pure ES module (ESM). In a CommonJS (CJS) environment—like your default Firebase Functions setup—using the standard require() to load an ES module isn’t allowed. This is why you see errors like:

Error [ERR_REQUIRE_ESM]: require() of ES Module ... not supported.

---

Approaches

1. Use Dynamic Imports in a CJS Module

In a CommonJS file you can work around this limitation by using dynamic import() instead of a top-level import. Since dynamic import() is asynchronous, you’ll need to handle it accordingly. For example:

JAVASCRIPTCopied
// CommonJS file (lib/index.js)
async function initApp() {
  const { App } = await import('@octokit/app');
  const app = new App({ /* configuration options */ });
  // ... use app
}

initApp().catch(console.error);

By doing this, you aren’t forcing a synchronous require() of the ES module. However, note that your functions that call this code now need to be asynchronous.

2. Switch to an ESM Setup

If using dynamic imports is too disruptive (or your codebase heavily relies on synchronous module loading), consider converting your Firebase Functions project to ESM. Firebase Functions now support Node 16+ which allows you to take advantage of ESM. To do so:

1. In your package.json, add:

   JSONCopied
   {
     "type": "module",
     // ...other configurations
   }

2. Ensure that your tsconfig or compiler settings (if you’re using TypeScript) target the module settings compatible with ESM (like "module": "ESNext" or "module": "Node16").
3. Rename files from .js to .mjs as needed (or use the "type": "module" trick).

This lets you use standard ES imports as documented, for example:

JAVASCRIPTCopied
// ESM file (index.mjs)
import { App } from '@octokit/app';

const app = new App({ /* configuration options */ });
// ... use app

---

Considerations

• Why not use CommonJS require()?
  Because @octokit/app is published as ESM, it doesn’t expose a CommonJS interface. There isn’t a “dual package” logic available that automatically provides a CJS build.

• Type Resolution Errors:
  When you try to import from "octokit", you run into type resolution errors because the package’s typings expect a modern ES module resolution system. Switching to Node16 or using dynamic imports in your CJS environment can help resolve these issues.

---

Conclusion

To work with Octokit in your Firebase Functions without changing your entire module system:

• Use dynamic imports to load ESM modules in a CommonJS file.
• Or consider migrating your project to an ESM setup (which may be easier long term since Firebase Functions now support Node 16+).

Choose the approach that best suits your project’s architecture.