TypeError cannot redefine property: default

[dan-hill-nutrien]

When using withLDProvider in our react application using this code:

export default withLDProvider({ clientSideID: ${appConfig.launchDarklyId} })( App );

we are getting the following error:

`TypeError: application 'dxp-sidebar-app' died in status LOADING_SOURCE_CODE: Cannot redefine property: default
(anonymous function)
./node_modules/launchdarkly-react-client-sdk/lib/withLDProvider.js:34
31 | o[k2] = m[k];
32 | }));
33 | var __setModuleDefault = (this && this.__setModuleDefault) || (Object.create ? (function(o, v) {

34 | Object.defineProperty(o, "default", { enumerable: true, value: v });
35 | }) : function(o, v) {
36 | o["default"] = v;
37 | });`

SDK version
2.18.1

[internettrans]

This is caused by microsoft/TypeScript#38540 and occurs when the React module provided to react-client-sdk is an ES module instead of a CJS module.

This can happen when React is converted to an ES module by SystemJS. In that case, the following workaround can be employed to fix it:

<script src="https://cdn.jsdelivr.net/npm/systemjs/dist/system.js"></script>
<script>
  (function() {
    const originalInstantiate = System.constructor.prototype.instantiate;
    System.constructor.prototype.instantiate = function() {
      return originalInstantiate
        .apply(this, arguments)
        .then(function(register) {
          const originalFn = register[1];
          register[1] = function(_export) {
            _export("__esModule", true);
            return originalFn.apply(this, arguments);
          };
          return register;
        });
    };
  })();
</script>

[bwoskow-ld]

Thank you @joeldenning for the response and workaround!

@dan-hill-nutrien - can you provide us with your TypeScript version? From my reading of the linked GitHub issue, this issue appears to have been introduced in TS 3.9.

[dan-hill-nutrien]

Yes thank you @joeldenning the work around works like a charm!

@bwoskow-ld I am using typescript@3.6.3

[internettrans]

The relevant typescript version is the one used by launchdarkly's react-client-sdk:

react-client-sdk/package.json

Line 56 in a5716dd

"typescript": "^3.9.2"

Also note that this error only occurs with the esModuleInterop flag, as noted in the typescript issue I linked to above. Launch darkly is using that flag as shown here:

react-client-sdk/tsconfig.json

Line 13 in a5716dd

"esModuleInterop": true,

See lines 41 and 42 of https://unpkg.com/browse/launchdarkly-react-client-sdk@2.18.1/lib/withLDProvider.js, which show that the code published by launchdarkly to unpkg has the bug in it (due to typescript@3.9.2 compiling it in such a way where it's possible to throw an error).

Lines 41 and 42 are the ones throwing an error. The code I shared works around the error by causing the if statement on line 39 to short circuit.

The reason that the error is thrown is that any ESM version of react is an object with an enumerable property called default. Contrast that with the CJS version of react, which does not have a property on it called default.

The typescript runtime currently throws errors whenever a dependency has a default property without also having the __esModule property on it. Note that __esModule is not on standards track and is not present on real ES modules created by browsers. For that reason, SystemJS also does not apply the __esModule property to its modules, which are a close approximation to native ES module objects. The SystemJS-specific workaround I provided will forcibly apply the __esModule to all SystemJS modules, which works around the bug in typescript due to the check on line 39

The options I see:

1. Use the workaround I provided above
2. Downgrade typescript inside of react-client-sdk until the typescript bug has been fixed.
3. Remove the esModuleInterop flag from react-client-sdk's tsconfig.json until the typescript bug has been fixed.

[bwoskow-ld]

Thanks again @joeldenning for your guidance here.

@dan-hill-nutrien - we've released version 2.18.2 of the React SDK which downgrades to TypeScript 3.8.3 (or more specifically, ~3.8.3 so that the SDK isn't built with 3.9.x unless we explicitly update our dependencies to do so).

I also see that there is a TypeScript PR to fix the underlying issue. We'll pick that up in a future React SDK release.

Cheers,
Ben

[internettrans]

This is now fixed in typescript@3.9.4, which is currently released under the dev dist-tag.

The react-client-sdk project should be able to upgrade from 3.8.3 to 3.9.4 without worry of regression.