ArangoDB generates a JS version of that DAT file already: https://github.com/arangodb/arangodb/blob/devel/js/common/bootstrap/errors.js

This is out of scope for arangojs as the error codes can change in new versions of ArangoDB but there may be a way to get these from another npm module in the near future.

This is out of scope for arangojs as the error codes can change in new versions of ArangoDB

Why does this specifically apply to error codes? How are they any different from other parts of the API?

• If a new version of arangodb introduces a new error code, of course I need to update arangojs to have this new error code, just like I would need to update arangojs to use a new API, or to support additional options on an existing API
• If a new version of arangodb removes an error code, arangojs could keep them and mark them as deprecated until the release of a new arangojs version that drops support for older arangodb versions - just like it's probably done for API removals.

If there is too much fuctuation in error code meanings for even arangojs to have a mapping, I wonder how I could possibly write an application or a library that supports multiple ArangoDB versions. I hope the error codes don't just arbitrarily change without announcement.

I'm fine with this not being implemented, just thought I could get rid of the definition file in our open-source library, but I don't quite understand how it would not fit into arangojs.

I think a case could be made for publishing the error codes separately on npm. I'll raise this for internal discussion.

added generators:
#21623