Latest version creates runtime error when bundled: `Class constructor BaseService cannot be invoked without 'new'`
bwilloughby1 opened this issue · 10 comments
Since this issue was originally found when referencing ibm-watson package, the ticket was originally created there. It appears to be an issue derived from referencing the node-cloud-sdk-core package. The last version of the ibm-cloud-sdk-core that is able to be bundled is 2.17.0. The details to reproduce the issue are contained in the ticket below:
@dpopp07 I wonder if this problem is due to the changes in this commit?
3a912c6#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519
That was merged in right after the 2.17.0 release.
I lost track of this issue but I was thinking the same thing. @CarstenLeue do you know if your changes could've affected this? Is there something that downstream users need to update in their build if they are bundling their code?
@CarstenLeue I found this stackoverflow article that seems relevant:
https://stackoverflow.com/questions/51860043/javascript-es6-typeerror-class-constructor-client-cannot-be-invoked-without-ne
There are couple of answers there that recommend modifying tsconfig.json to set "target" to something like "ES2017" or "ES6".
Do you have any insight into whether this should work?
Edit: currently our tsconfig-es6.json file sets target to "ES6". Could we also set target to "ES6" in tsconfig.json? Not sure of the ramifications of that for users.
This problem was caused by some recent changes to enable the node core library to be "tree shakeable" (these changes were delivered in version 2.17.1)
Specifically, the "module" entry in the node core's package.json file specifies the es6 module entry point for
the library, and this was being used by webpack when doing the tree shaking, despite the fact that the Watson Node SDK does not specify an es6 module.
To make a long story short... a tactical fix to the node core will be made to remove the 'module' entry point from package.json. This change will be delivered in a new patch release (e.g. 2.17.7). This should allow a new patch release of the Watson Node SDK to be delivered that uses this new node core version, and that should allow webpack to work on the application.
In addition, we'll need to work on a longer-term strategy for eventually adding back the 'module' entry point in the node core and roll out changes to Node SDKs so that they can properly consume the node core's es6 module and themselves support tree shaking.
Thank you for your efforts in addressing this issue. We will watch for the patched release.
@bwilloughby1 It looks like the Watson Node SDK is currently using version 2.14.3 of the node core, but you encountered this problem while trying to use 2.17.1+ of the node core library. Just curious how you ended up in that situation? Are you sort of forcing the use of a newer core as compared to the version that the Watson Node SDK was built and delivered with?
@padamstx The Watson SDK uses carat ^ notation for their dependencies, which means that a fresh install will use the latest 2.x.x version of the core
@bwilloughby1 We've now published version 2.17.7 of the node core. Could you re-try your scenario to make sure that the problem has been fixed?
@bwilloughby1 Please reopen this if your re-try attempt continues to see the problem
This issue has now been resolved with the latest sdk version. Thank you!