pdf-parse dependency crashes on Node.js 24+ during module initialization

## Summary

The `pdf-parse@1.1.1` dependency used by `@memberjunction/core-actions` and `@memberjunction/actions-bizapps-formbuilders` crashes on module
initialization in Node.js 24+ due to a bug in how it detects "debug mode".

## Affected MJ Packages

- `@memberjunction/core-actions@4.2.0`
- `@memberjunction/actions-bizapps-formbuilders@4.2.0`

## Error Message

Error: ENOENT: no such file or directory, open './test/data/05-versions-space.pdf'
at Object.openSync (node:fs:559:18)
at Object.readFileSync (node:fs:443:35)
at Object. (node_modules/pdf-parse/index.js:15:25)
at Module._compile (node:internal/modules/cjs/loader:1761:14)
at Object..js (node:internal/modules/cjs/loader:1893:10)
at Module.load (node:internal/modules/cjs/loader:1481:32)
at Module._load (node:internal/modules/cjs/loader:1300:12)
at TracingChannel.traceSync (node:diagnostics_channel:328:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:245:24)
at loadCJSModuleWithModuleLoad (node:internal/modules/esm/translators:339:3)

## Root Cause

In `pdf-parse/index.js` (lines 6-26):

```javascript
let isDebugMode = !module.parent; // BUG: unreliable in Node.js ESM/CJS interop

if (isDebugMode) {
let PDF_FILE = './test/data/05-versions-space.pdf';
let dataBuffer = Fs.readFileSync(PDF_FILE); // Crashes here
// ...
}

The check !module.parent is unreliable because:

1. module.parent is deprecated since Node.js 14
2. In ESM/CJS interop scenarios (common with Node.js 24), module.parent can be undefined instead of a module object
3. This causes !module.parent to evaluate to true, triggering the debug code path
4. The debug code tries to read a test file that isn't included in the published npm package

Why This Happens Now

- Node.js 24 has stricter ESM/CJS module resolution
- The MJ CLI (mj codegen manifest) loads action packages at startup
- This triggers the pdf-parse module initialization, which crashes before any user code runs

Reproduction Steps

1. Create a project using @memberjunction/core-actions or @memberjunction/actions-bizapps-formbuilders
2. Use Node.js 24+
3. Run any command that loads the MJ action packages (e.g., mj codegen manifest)
4. Observe the ENOENT error

Recommended Fix

Replace pdf-parse with pdf-parse-debugging-disabled in the affected packages' package.json:

// In package.json dependencies
- "pdf-parse": "^1.1.1"
+ "pdf-parse": "npm:pdf-parse-debugging-disabled@^1.1.1"

The pdf-parse-debugging-disabled fork is a drop-in replacement that simply sets isDebugMode = false, preventing the buggy code path from executing.

Alternatively, the import could be changed to lazy-load pdf-parse only when actually needed:

// Instead of top-level import that runs at module init
import pdfParse from 'pdf-parse';

// Use dynamic import only when the functionality is needed
async function parsePdf(buffer: Buffer) {
const pdfParse = (await import('pdf-parse')).default;
return pdfParse(buffer);
}

Workaround for Consumers

Until this is fixed upstream, consumers can add this to their root package.json:

"pnpm": {
"overrides": {
"pdf-parse": "npm:pdf-parse-debugging-disabled@1.1.1"
}
}

Or for npm/yarn:

"overrides": {
"pdf-parse": "npm:pdf-parse-debugging-disabled@1.1.1"
}

References

- https://gitlab.com/AuTomKenT/pdf-parse/-/issues/24 (and many related issues in that repo)
- The pdf-parse package hasn't been updated since 2019
- https://www.npmjs.com/package/pdf-parse-debugging-disabled

Environment

- Node.js: 24.x
- MemberJunction: 4.2.0
- OS: Linux (GitHub Actions runner), also reproducible on macOS