Skip to content
This repository has been archived by the owner on Apr 24, 2023. It is now read-only.

weird behaviour when bundled #142

Closed
kenshyx opened this issue Apr 13, 2018 · 17 comments
Closed

weird behaviour when bundled #142

kenshyx opened this issue Apr 13, 2018 · 17 comments
Assignees
Labels
exp/expert Having worked on the specific codebase is important kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up

Comments

@kenshyx
Copy link

kenshyx commented Apr 13, 2018

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
Copy link
Author

kenshyx commented Apr 13, 2018

prod

dev

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

@kenshyx
Copy link
Author

kenshyx commented Apr 17, 2018

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 daviddias added the status/ready Ready to be worked label Jun 4, 2018
@daviddias
Copy link
Member

@fsdiogo can you look into this one?

@daviddias daviddias added kind/bug A bug in existing code (including security flaws) exp/expert Having worked on the specific codebase is important P1 High: Likely tackled by core team if no one steps up labels Jun 4, 2018
@fsdiogo
Copy link
Member

fsdiogo commented Jun 5, 2018

Yes, I'll take a look.

@fsdiogo
Copy link
Member

fsdiogo commented Jun 6, 2018

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
Copy link
Author

kenshyx commented Jun 6, 2018

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
Copy link
Member

fsdiogo commented Jun 6, 2018

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

@kenshyx
Copy link
Author

kenshyx commented Jun 6, 2018

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
Copy link
Member

fsdiogo commented Jun 6, 2018

What version of IPFS are you using?

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

mangle: {
	keep_classnames: true
}

@kenshyx
Copy link
Author

kenshyx commented Jun 6, 2018

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
Copy link
Author

kenshyx commented Jun 6, 2018

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

@fsdiogo
Copy link
Member

fsdiogo commented Jun 6, 2018

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

@kenshyx
Copy link
Author

kenshyx commented Jun 6, 2018

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
Copy link
Member

fsdiogo commented Jun 6, 2018

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

@fsdiogo
Copy link
Member

fsdiogo commented Jun 6, 2018

@kenshyx can I close this issue?

@kenshyx
Copy link
Author

kenshyx commented Jun 6, 2018

Yes, thank you for your assistance!

@fsdiogo
Copy link
Member

fsdiogo commented Jun 6, 2018

No problem! 👌

@fsdiogo fsdiogo closed this as completed Jun 6, 2018
@ghost ghost removed the status/ready Ready to be worked label Jun 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
exp/expert Having worked on the specific codebase is important kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up
Projects
None yet
Development

No branches or pull requests

3 participants