Code Modernization Efforts?

[akaustav]

I understand that this repository was created almost 10 years ago, and the Apigee Team isn't really promoting Apigee Edge to new customers. However, there are many folks who are still on the Apigee Edge platform and don't have the resources to migrate into Apigee X yet. I really like this project leverages the Apigee Edge APIs to accomplish many operations and would love to contribute to modernizing the code on this repository. If there are no ongoing efforts in that direction and the owners / maintainers of this repository are not opposed, I have the following items on my mind:

1. Use ECMAScript modules syntax instead of CommonJS modules
2. Replace all instances of older JavaScript syntax with their newer counterparts - like:
   1. Use const and let instead of var.
   2. Use Arrow Functions instead of traditional function expressions.
   3. Use the new node: prefix when requiring / importing modules built into Node.js - like: node:fs, node:path, node:util, etc.
   4. Use async / await instead of Promises / callback APIs.
   5. etc.
3. Replace the outdates / unmaintained 3rd party packages with contemporary solutions - preferably techniques inbuilt into the newer versions of Node.js. Like:
   1. Replace the argument parsing techniques using the now seemingly unmaintained cli-table package with the inbuilt Argument Parsing utility - that introduced in Node.js v18.3.0 and was made stable in Node.js 20.0.0
   2. Replace the postman-request package with the fetch module inbuilt in Node.js - introduced in Node.js v17.5.0, and was made stable in Node.js 21.0.0
   3. Replace the mocha package for Unit Testing with the inbuilt Test Runner module - that was introduced in Node.js v18.0.0, and was made stable in Node.js 20.0.0)
   4. Replace the fs-extra package with the inbuilt Recursive File System operations. For example, fs.copy() can be replaced with fs.cp(src, dest, { recursive: true })
   5. etc.

Is there any appetite for such changes?
If so, I would be happy to contribute to this repository.

[akaustav]

Attempting to get the attention of @DinoChiesa / @theganyo / @mukundha / @whitlockjc - to this issue.

[akaustav]

Attempt number 2 to get the attention of @DinoChiesa / @theganyo / @mukundha / @whitlockjc - to this issue.

[akaustav]

Attempt number 3 to get the attention of @DinoChiesa / @theganyo / @mukundha / @whitlockjc - to this issue.

[DinoChiesa]

Hey there, Ameet!

I think the ideas you suggested so long ago are good ones. The effects of entropy on the apigeetool-node tool is now accumulating: postman-request, mocha, and so on.

Any significant change requires attention and time, and there is a cost -vs- benefit discussion. Migrating var to const is good hygiene; is that a high enough priority? I understand the desired to modernize other things, arrow functions, using promises.. but what is the concrete benefit, other than "modernizing"? Obviously if you were starting today, you'd use the modern APIs and interfaces. But this is an established tool; rewrites must be undertaken with care.

In general I think the appetite from the team will be to consider smaller, incremental changes with concrete benefits.

[akaustav]

Hey @DinoChiesa - thank you so much for responding, and for the kind words about the ideas! I completely agree with your framing: smaller, incremental changes with concrete benefits are the right way to approach this. Let me make the case for why some of these changes clear that bar - specifically around security.

The Core Argument: Fewer Dependencies = Smaller Attack Surface

The most impactful modernization here isn't stylistic - it's eliminating third-party dependencies in favor of Node.js built-ins. Each dependency in package.json is a potential vector for supply chain attacks (malicious updates, compromised maintainer accounts, typosquatting, dependency confusion, etc.). The security community has become acutely aware of this risk in recent years.

Looking at the current dependencies in package.json, at least 4 packages can be replaced outright with Node.js built-ins today, with zero functional regression:

Package	Replacement	Available Since
postman-request	fetch (built-in)	Node.js ≥ 18 (stable in v21)
fs-extra	fs.cp(), fs.rm() with { recursive: true }	Node.js ≥ 16
cli-table	util.styleText() / native string formatting	Node.js ≥ 20
mocha (devDep)	node:test (built-in Test Runner)	Node.js ≥ 18 (stable in v20)

postman-request is the highest-priority item here. It is a fork of the now-deprecated request package, which was archived and abandoned. It carries a large sub-dependency tree, and since it is no longer receiving security patches, any vulnerability discovered in it or its transitive dependencies will never be fixed. The project currently requires node >= 16.13.1, but fetch has been stable since Node.js 21. Bumping the engine requirement to >= 20 (Node.js 24 is the current LTS) unlocks every one of these replacements at once.

A Concrete, Incremental Plan

I'm not proposing a big-bang rewrite. Here's how I'd approach it incrementally - each step is independently mergeable and reviewable:

1. PR group 1: Replace postman-request with native fetch. This is the highest-security-impact change.
2. PR group 2: Replace fs-extra with native fs recursive operations.
3. PR group 3: Replace mocha (devDep) with node:test.
4. PR group 4: Stylistic/hygiene changes (var → const/let, arrow functions, node: prefix on built-in imports). These are lower priority but improve maintainability and linter compliance.

Each PR can be evaluated on its own merits, and nothing prevents us from stopping at any step.

On the "modernizing for its own sake" question

You're right that var → const alone isn't a compelling reason to touch an established tool. But the postman-request and fs-extra replacements are not cosmetic - they are direct reductions in the number of third-party packages that users of this tool install into their environments. Every developer who runs npm install apigeetool today is pulling in those dependency trees. That's the concrete, practical benefit.

I'm happy to start with PR group 1 if the maintenance team (including yourself) is open to it. I'll make sure the PR is well-tested and minimally scoped. Would love your sign-off to proceed!