webpack-asset-relocator-loader

Currently this library tries to recursively include all libraries in a directory when a file is detected in the same directory, which is probably fine in most cases (but not when you're trying to build a native library with Rust because its directory is included due to the files inside, which aren't needed in most cases and increase the final directory size) This notably affects Proton Pass (which has a native Rust component) by increasing the size of the final file as prepared by Electron Forge Custom emit filter has no effect here because the emitting is a consequence of the files (and they aren't passed through the filter-compatible functions either) Let me know if you need a simple test case for this Edit: #73 vaguely mentions this issue (but it doesn't seem to be a good enough bug report)

Now that the dust has settled, I'm repurposing this PR to focus on simplifying the build process by removing the dependency on ncc and replacing it with a direct webpack build. This change helps resolve the cyclic dependency and avoids some of the quirks associated with ncc. The tradeoff is that we now need to maintain a small custom webpack configuration, and there's a risk that certain edge cases previously handled by ncc may not be fully covered. Building the loader with webpack passes the same set of tests as the build script. This brings us to a decision point: either continue using ncc or move forward without it. This, perhaps, provides a fallback in case ncc introduces issues again. I'm working on fixing the tests for #193. While running them, the only intermittent failure I encountered was in , where the number of lines in the webpack output is being asserted. After running the tests multiple times, I observed that the output fluctuates between 16 and 17 lines. To address this, we could update the test to allow either value. 16 lines: 17 lines: