Imports undefined in React/Next.js

[kieferenriquez]

Hey guys,

Getting Type Error using this parser library with TextractClient/AnalyzeExpenseCommand from https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/clients/client-textract/

Unhandled Runtime Error TypeError: amazon_textract_response_parser__WEBPACK_IMPORTED_MODULE_5__.TextractExpense is not a constructor

Source code below: https://github.com/kieferenriquez/qidp/blob/main/src/pages/payables/index.tsx

Thanks, Kiefer

[athewsey]

Hi @kieferenriquez and thanks for providing example code! Afraid I've not been able to replicate your error though :/ As when trying to build your app I get:

Type error: Cannot find module '../../src/aws-exports' or its corresponding type declarations.

...and am not sure what you have in that file.

Your general usage looks correct to me and seems pretty in line with our integration test for TextractExpense. In a fresh vanilla TypeScript project I am also able to do similar import + call with no problem.

It looks likely to be some sort of packaging issue, which might require a change on our end, but I'm struggling without an example to dig in to. Could you fix the qidp repo (or add instructions) for building from a fresh environment?

[kieferenriquez]

Hello @athewsey,

Appreciate the response here, it's a configuration file for aws-amplify. I have commented any relevant amplify for now.

You can try to build it again? install dependencies and npm run dev on your local and go to http://localhost:3000/payables

Would be great if this packaging issue will be fixed this parser will be helpful for a lot of people.

Thanks, K

[athewsey]

Taking your updated version of the code (and also commenting out the Amplify config in _app.tsx) I seem to be able to navigate to the /payables page just fine (though since I've not set up Amplify/AWS, can't test the functionality after that).

With a couple of minor unrelated typing fixes (this in Payables and reader.result) I also seem to be able to npm run build without errors.

The only thing I notice is that package-lock automatically got quite a few changes from your checked-in version, when I npm installed. Perhaps you could try removing and re-installing your node_modules folder? It could be you have some conflicts in there.

My test environment here is NodeJS v18(.15)

[kieferenriquez]

@athewsey fixed typing issue and re-installed node packages by deleting the folder and running npm i

Is there any way you could setup your local env?

ACCESSKEYID= SECRETACCESSKEY=

This way you could see the response and error?

Cheers

[kieferenriquez]

Hi mate @athewsey

Any news from your side?

Cheers, K

[kieferenriquez]

@athewsey and team, any news here?

[kieferenriquez]

don't you guys think it's a compatibility issues between your libs?

"@aws-sdk/client-textract": "^3.312.0", "amazon-textract-response-parser": "^0.2.0",

@athewsey

[athewsey]

Hi @kieferenriquez & sorry for the delay - I was struggling to reproduce but one of our support engineers was able to get an example working.

There is some kind of issue with module resolution when using the library in the kind of React/NextJS setup you have here: The underlying cause of your ... is not a constructor error seems to be that any ("real", ignoring types/interfaces) object you import from TRP - like TextractExpense - is not raising any import error, but is just getting set to undefined.

The error doesn't seem to be related to the combination of @aws-sdk and amazon-textract-response-parser in particular: Just something about this project's Typescript/webpack/module resolution settings is interacting badly with TRP's packaging. As far as I can tell the @aws-sdk/client-textract package itself seems to be working no problem, right?

The TRP NPM package contains several builds for different environments: dist/browser (IIFE for direct-in-browser execution with no framework), dist/cjs (CommonJS based module resolution like Node), dist/es (Native ES modules), and dist/umd (Universal Module Definition). The version used when the library imported is controlled by various fields in our package.json, like main, module, exports, etc.

I've been hacking around in the node_modules folder of the actual test app (where TRP gets installed) to try and edit these package.json fields to find a working combination - but so far no luck. I can say that if you instead import {...} from "amazon-textract-response-parser/dist/cjs" then npm run dev seems to work, but npm run build will fail because it doesn't correctly find the TypeScript type definitions (which are in dist/types).

Looking at @aws-sdk/client-textract (as installed in your node_modules folder) as an example of a working module, you'll see that our setups are actually very similar! E.g. they have dist-cjs/index.js instead of dist/cjs/index.js, but same general pattern... I'm hoping we can find some way of tweaking the TRP package.json and/or distributed structure to make it work correctly in this context (like aws-sdk/client-textract does), but haven't found a way to yet...

[athewsey]

OK good news - we have a possible fix!

Please can you try updating your dependency to the new v0.2.2-alpha.1 as shown below:

    "amazon-textract-response-parser": "0.2.2-alpha.1",

I think this should resolve the import issues for your use case?

[kieferenriquez]

awesome, great work! @athewsey that fixed my issue!

[athewsey]

Thank you for confirming! Have now released mainline version v0.2.2 including this fix, and merged the attached PR: Closing this issue as fixed 😄