weird behaviour when bundled

[kenshyx]

If I'm starting my js-ipfs node with this config:

{
    Addresses: {
        Swarm: [
            '/dns6/akasha.cloud/tcp/443/wss/p2p-webrtc-star'
        ],
        API: '',
        Gateway: ''
    },
    Discovery: {
        MDNS: {
            Enabled: false,
            Interval: 10
        },
        webRTCStar: {
            Enabled: true
        }
    },
    EXPERIMENTAL: {
        pubsub: true
    }
}

On my local development environment it will work as expected, by using wss when connecting to signalling-server.

On production bundle(using webpack 4), it always tries to connect using ws ...:

websocket.js:112 Mixed Content: The page at 'https://akasha.network/#/dashboard/1522944906003-0x551df15db6f9f834c6b5795183190582452cb10c' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://akasha.cloud:443/socket.io/?EIO=3&transport=websocket'. This request has been blocked; this endpoint must be available over WSS.

I managed to find the problem on this line https://github.com/libp2p/js-libp2p-webrtc-star/blob/master/src/utils.js#L15 . On the production version it always returns false from this https://github.com/multiformats/js-multiaddr/blob/master/src/index.js#L416.

Both versions(develop and prod) return the same codes for swarm multiaddress when .protos() is called` [55 6 478 275 421] => 55 is resolvable. Any ideas? :/

[kenshyx]

On production always returns false but when evaluated from console it returns true ✝️

[kenshyx]

It seems that uglifyjs breaks that line when it has mangle: true https://github.com/mishoo/UglifyJS2/tree/harmony#mangle-options, this is enabled by default for webpack 4 in mode: 'production'

I managed to make an usable build(it connects by using wss now) by disabling that option but the overall bundle size increased 35%.

[daviddias]

@fsdiogo can you look into this one?

[fsdiogo]

Yes, I'll take a look.

[fsdiogo]

Hey @kenshyx, in your UglifyJS config try passing this option:

compress: {
    unused: false
}

Check ipfs/js-ipfs#1321 and ipfs/aegir#214 for reference.

[kenshyx]

Hey @fsdiogo , I've tried with that option, now I get the console full with this:

bundle.js:1 warning, stream-to-pull-stream: 
the wrapped node-stream does not implement `destroy`, 
this may cause resource leaks.
i @ bundle.js:1
(anonymous) @ bundle.js:1
a @ bundle.js:1
(anonymous) @ bundle.js:1
a @ bundle.js:1
(anonymous) @ bundle.js:1
16:45:15.961 bundle.js:1 Uncaught Error: BlockStream: write after end

[fsdiogo]

Hmm 🤔 is the project on GitHub so I can take a look?

[kenshyx]

It is on github but in a private repo. This is the relevant webpack config part I'm using right now for staging build:

mode: 'production',
    optimization: {
        minimizer: [
            new UglifyJsPlugin({
                uglifyOptions: {
                    compress: {
                        unused: false
                    },
                    output: {
                        comments: false,
                        ascii_only: true,
                    }
                },
                cache: true,
                parallel: true,
                sourceMap: true
            }),
            new OptimizeCssAssetsPlugin({
                cssProcessorOptions: {discardComments: {removeAll: true}},
                canPrint: true
            }),
        ]
    }

You can check the aplication here. If you leave the page opened for 5 minutes without doing anything that error starts to pop in console.

[fsdiogo]

What version of IPFS are you using?

To allow mangling before version 0.29.0, you have to pass:

mangle: {
	keep_classnames: true
}

[kenshyx]

I forgot to add that you need to disable the ipfs companion extension to have a local js-ipfs node started.
I use ipfs v0.29.3

[kenshyx]

This is a recording of the error https://ipfs.io/ipfs/QmQUgpoVYGjonxeUAimnyWPdzzsyLX7FGjBMJZbG8Dfb2F

[fsdiogo]

Looks like there is a fix incoming, check ipfs/js-ipfs#1379.

[kenshyx]

Hmm this might not be related to production build because I managed to replicate it also in development. So there might be an issue with stream-to-pull-stream and block-stream packages that ipfs uses.

[fsdiogo]

Yeah, we just came to the same conclusion at the same time 😄

[fsdiogo]

@kenshyx can I close this issue?

[kenshyx]

Yes, thank you for your assistance!

[fsdiogo]

No problem! 👌