[JS] Compatibility Issue with Apache Arrow Library in Angular Application

[pratikproths04]

Describe the bug, including details regarding any error messages, version, and platform.

We are encountering an issue related to the compatibility of the Apache Arrow library version (14.0.2) with our Angular application (version 16.2.0) running on Node.js version 18.16.0. During the application build process, we are utilizing setTimeout in multiple places, resulting in errors indicating "Type 'timeout' is not assignable to type 'number'." We need assistance in resolving this issue or guidance on obtaining a compatible version of the Apache Arrow library that supports the specified Angular and Node.js versions.

Component(s)

JavaScript

[vivek1729]

Facing the same issue in our client integration as well. Looks like the arrow package import pulls in some node types that pollute the globals for browser projects. Any guidance on how to resolve this issue?

[andriy101]

try to replace @types/node with @types/web by running: npm i @types/node@npm:@types/web -D

[domoritz]

Can you provide a specific (minimal) reproduction? Also, make sure your bundler pulls in Arrow.dom not Arrow.node.

[vivek1729]

@domoritz, @trxcllnt - I did try importing specific classes from Arrow.dom in our code but that didn't seem to work either. Can you elaborate more on how to pull in Arrow.dom and not Arrow.node? Are you referring to the type replacement pattern recommended by @andriy101 ?

I finally had some time to create a minimal repro for this typing issue. I've created the repo apache-arrow-angular-type-issue-repro to illustrate this issue. I simply used the angular cli tool to scaffold a very simple angular web app. The main changes to repro the issue can be found in app.component.ts.

Here are the repro steps:

• Clone the repo
• npm install at the project repo to install all the dependencies
• Uncomment line 12 i.e. the apache-arrow import line in app.component.ts
• Run ng serve at the project root

You'll start seeing build errors of this type as soon as you uncomment the import line for the apache-arrow package:

If you uncomment that line, the ng serve automatically picks up changes and builds without any errors.

I think the setTimeout example illustrates how the node types are getting pulled into the build with the apache-arrow package import.

Hope this helps clarify and debug the issue I shared earlier.

[domoritz]

Hmm, can you set the type to const timer: ReturnType<typeof setTimeout>? That would resolve the issue.

[vivek1729]

@domoritz , thanks for taking a look. Yes, I shared the minimal repro just as an illustration and I imagine that the re typing as you suggested should work for the minimal repro case. However, in our production code base there are 100s of errors related to the typing mismatch and it might not be feasible to refactor all the errors. It's most evident in the setTimeout and the setInterval use cases. Is there any way that the library can be bundled/imported so that the node types are not pulled in?

[domoritz]

It's odd that you get conflicts with node types. I don't really get yet why. However, to your question whether you can not pull them in that would be something your bundler does. It's not something I can make time to debug for you, though.

[jcludwig]

This is not an issue of bundling, the problem is with TypeScript compilation. I believe the root cause is probably the use of NodeJS types in compat.ts (https://github.com/apache/arrow/blob/2ae192b4aca6017a141dc52f78b5dec4ad2f2874/js/src/util/compat.ts#L21). I believe this file must be getting imported through some path from the Arrow.dom.ts module. In my view the correct fix is for the apache-arrow project to make sure that the Arrow.dom module does not have any imports to NodeJS code, including types. Importing any module that imports these types will pollute the TypeScript type context since NodeJS declares ambient types that conflict with browser types.

[trxcllnt]

We should be able to remove the node types with a bit of duck-typing.

[vivek1729]

Thanks @jcludwig , @trxcllnt - should this issue be reopened since the root cause is probably in the sources of the library?