Warning related to webpack source maps: WARNING in ./node_modules/base64-arraybuffer/dist/base64-arraybuffer.es5.js

[BjoernKW]

Describe the bug

When using version 4.4.0 of socket.io-client in a React app created with create-react-app, which in turn uses webpack for creating source maps, I get the following warning when starting the app with npm run start:

WARNING in ./node_modules/base64-arraybuffer/dist/base64-arraybuffer.es5.js
Module Warning (from ./node_modules/source-map-loader/dist/cjs.js):
Failed to parse source map from '/project-directory/node_modules/src/index.ts' file: Error: ENOENT: no such file or directory, open '/project-directory/node_modules/src/index.ts'
@ ./node_modules/engine.io-parser/build/esm/decodePacket.browser.js 2:0-44 38:20-26
@ ./node_modules/engine.io-parser/build/esm/index.js 2:0-45 27:26-38 39:0-68
@ ./node_modules/engine.io-client/build/esm/socket.js 6:0-44 113:16-24 586:18-26
@ ./node_modules/engine.io-client/build/esm/index.js 1:0-37 2:0-18 3:24-39
@ ./node_modules/socket.io-client/build/esm/manager.js 1:0-75 23:4-25 116:22-28
@ ./node_modules/socket.io-client/build/esm/index.js 2:0-39 26:13-20 29:22-29 45:2-9 63:0-79
@ ./src/services/SocketClient.js 3:0-34 9:25-27
@ ./src/components/App/App.js 17:0-59 84:35-48
@ ./src/index.js 9:0-39 12:33-36

1 warning has detailed information that is not shown.
Use 'stats.errorDetails: true' resp. '--stats-error-details' to show it.

webpack 5.65.0 compiled with 1 warning in 2358 ms

To Reproduce

Socket.IO client version: 4.4.0

Client

import io from 'socket.io-client';
import {isAPIBaseURLValid} from '../utilities';

const API_BASE_URL = 'http://localhost:8080';

let socketClient;
if (isAPIBaseURLValid(API_BASE_URL)) {
    socketClient = io(API_BASE_URL);
    socketClient.on('connect', () => {
        console.log(socketClient.id);
    });
}

export default socketClient;

Expected behavior
No warning should be displayed

Platform:

• Device: Mac
• OS: macOS Monterey 12.1

[makchamp]

This error appears to be caused by the latest release of react-scripts (5.0.0)

Downgrading to v4 "resolves" the error
npm install --save --save-exact react-scripts@4.0.3

[TheAschr]

The issue actually appears to be with the underlying base64-arraybuffer library. I can reproduce this bug without the socket.io-client library.

Running this command before starting your react client will fix this issue:

sed -i '/# sourceMappingURL\=/d' ./node_modules/base64-arraybuffer/dist/base64-arraybuffer.es5.js

[NoahYarian]

The issue actually appears to be with the underlying base64-arraybuffer library. I can reproduce this bug without the socket.io-client library.

Running this command before starting your react client will fix this issue:

sed -i '/# sourceMappingURL\=/d' ./node_modules/base64-arraybuffer/dist/base64-arraybuffer.es5.js

After doing this I'm still seeing the issue, even with the reference to the sourcemap removed. I've run npm cache clean --force as well. What am I missing?

[darrachequesne]

Is there something we can fix on our side? Or should we open an issue at base64-arraybuffer?

[georgeiliadis91]

Can confirm I experienced the same issue, downgrading react-scripts fix this issue but caused some others.

[CBYMachumbe]

Can confirm I experienced the same issue, downgrading react-scripts fix this issue but caused some others.

yep, downgrading react-scripts caused other problems

[darrachequesne]

I've opened an issue there: niklasvh/base64-arraybuffer#32

As a workaround, if you have access to the webpack configuration, you can ignore the warnings with:

module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        enforce: "pre",
        use: ["source-map-loader"],
      },
    ],
  },
  ignoreWarnings: [/Failed to parse source map/],
};

Reference: https://webpack.js.org/loaders/source-map-loader/#ignoring-warnings

[kaaax0815]

As a workaround, if you have access to the webpack configuration, you can ignore the warnings with:

But is this possible in react without ejecting?

[darrachequesne]

@kaaax0815 unfortunately, I don't think this is possible.

We are waiting for a response from the maintainer of the base64-arraybuffer package. Else, I think we will have to temporarily fork the project to include it here.

[darrachequesne]

OK, so we went ahead and forked the base64-arraybuffer package.

This should be fixed by socketio/base64-arraybuffer@d30e7cc, included in engine.io-parser@5.0.3 (and thus in latest socket.io-client version, as it is a transitive dependency).

[darrachequesne]

Let's close this then. Please reopen if needed.

[diegodorado]

OK, so we went ahead and forked the base64-arraybuffer package.

This should be fixed by socketio/base64-arraybuffer@d30e7cc, included in engine.io-parser@5.0.3 (and thus in latest socket.io-client version, as it is a transitive dependency).

But, where is that latest socket.io-client version?

[ElmouradiAmine]

No need, as @darrachequesne mentioned, the update of engine.io-parser@5.0.3 is suffisant. If you still have the issue delete node_modules, clear the cache and try again.

[hunterwilhelm]

No need, as @darrachequesne mentioned, the update of engine.io-parser@5.0.3 is suffisant. If you still have the issue delete node_modules, clear the cache and try again.

This worked for me too. A dependency's dependency is had been updated, so it seems that there is no need for a version increment.

[diegodorado]

I guess then my issue is with socket.io-client that is pointing to the 4.1.1 parser version ...

[ElmouradiAmine]

@diegodorado try to delete the .lock file.

[diegodorado]

That is a bit risky on the project I am working on... any other way to do it without blindly updating everything?

[darrachequesne]

@diegodorado you should be able to update the version of the engine.io-parser package with:

npm update --depth=9999 engine.io-parser 

After that, npm ls engine.io-parser should return:

├─┬ socket.io-client@4.4.1
│ └─┬ engine.io-client@6.1.1
│   └── engine.io-parser@5.0.3

[diegodorado]

Thank you @darrachequesne , I ended up doing the following (b/c I am not using npm)

• remove engine.io-client from package.json
• run yarn
• undo the removal
• run yarn again

And then the yarn.lock got updated, Thank you all!