running out of memory? memory leak?

[roshkins]

In order to troubleshoot, I need:

• A bundle that doesn't work, preferably as minimal as possible.
• Your configuration that you passed with the -c argument when debundling.
• The EXACT command you ran to debundle.

I was trying to debundle http://pdfkit.org/demo/bundle.js with a configuration of { "type": "browserify", "entryPoint": 1, "knownPaths": { } } I noticed it was running out of ram, so I gave it all I got by executing: node --max_old_space_size=15000 C:\Users\roshkins\AppData\Roaming\npm\node_modules\debundle\src\ index.js -i .\bundle.js -o .\debundle\ -c .\debundle.config.json but it seemed to just eat up a lot of ram :( and it feels liek a memory leak. I hope @1egoman can figure it out, because I can't seem to get the build process for pdfkit working with react.

[1egoman]

@roshkins Thanks for trying out the debundler!

I think your bundle probably has some cyclical dependencies. Right now, this project chokes on those (basically, there's a recursive function here that creates a dependency tree for each module, and when a module depends on itself the internal collections grow to an infinite size, eating up all the memory on your system)

I tried to solve cyclical dependencies, here's my attempt: https://github.com/1egoman/debundle/tree/require-cyclical Basically, the above keeps track of the history as we dive down each tree leg. When the code visits a node that has already been visited (ie, cyclical) then it stops traversal down that leg. Because of this approach, the output most likely won't be perfect, and might require some hand editing to be able to be recompiled. Give that branch a try.

But that being said, trying to decompile a bundle to get around fixing a build process probably is going to be a bad idea. This project was more of an experiment and something that isn't guaranteed to work well (if at all) on every bundle. Your time is much better spent getting the build process to work for the package in question.

[roshkins]

I got the compiled binary to work. It turns out my linter was throwing errors that seemed to be runtime errors but weren't because they look very similar. I was hoping the debundler could give me insight into the dependency tree.

On Sat, Jun 3, 2017, 3:52 AM Ryan Gaus notifications@github.com wrote:

@roshkins https://github.com/roshkins Thanks for trying out the debundler!

I think your bundle probably has some cyclical dependencies. Right now, this project chokes on those (basically, there's a recursive function here https://github.com/1egoman/debundle/blob/master/src/utils/getModulePath.js#L5 that creates a dependency tree for each module.)

I tried to solve cyclical dependencies, here's my attempt: https://github.com/1egoman/debundle/tree/require-cyclical Basically, the above keeps track of the history as we dive down each tree leg. When the code visits a node that has already been visited (ie, cyclical) then it stops traversal down that leg. Because of this approach, the output most likely won't be perfect, and might require some hand editing to be able to be recompiled. Give that branch a try.

But that being said, trying to decompile a bundle to get around fixing a build process probably is going to be a bad idea. This project was more of an experiment and something that isn't guaranteed to work well (if at all) on every bundle. Your time is much better spent getting the build process to work for the package in question.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/1egoman/debundle/issues/4#issuecomment-305967550, or mute the thread https://github.com/notifications/unsubscribe-auth/AAkQHcR_XAVCKJI_WJVh4HiLEAj9Cuo0ks5sATrXgaJpZM4Nu0qY .