Caleb Boyd

Yeah the approach that node-packer uses is effectively one level deeper on the file system 'hacks' that nexe performs. I don't have bandwidth to maintain something on that level -...

The largest changes in 4 have to do with build time dependency resolution. If you don't have any issues bundling your application there are very few differences from 3.X

Yes, once 2.0 is stable, #322 is similar.

Started working on this https://github.com/nexe/nexe/blob/b8229847767a9fae1a639c7a1cdde16ae5dde56f/plugins/nexe-daemon/src/index.ts Right now I'm thinking it will work like so: `my-app.exe install C:\path\to\files` I'd love to get other ideas

Thanks @FloMaetschke, @palavrov. I think rather than make the executable compatible with windows service handles (likely quite an undertaking) -- and would require building from source everytime. I'll use a...

@george-kar I'm prioritizing #418. As soon as that is resolved, this will be implemented

Nexe will analyze your source and only include the needed files, this process isn't always deterministic for commonjs. Is there a specific error or file that can't be required?

@chassy33 If you can build your app without the `-r "./node_modules/**"` option and then run it without node_modules, with `DEBUG="nexe:require" myapp` it should reveal the package/path/file that is failing to...

Nice find 👏 This seems perfect. The "bundling" system currently in place is loosely based on zip/asar... but is also a gross/fast hack, because something like this didn't exist.

Thanks for tackling this! Clearly I did not account for anyone else's use case but this solves it pretty nicely I think. I need to run a few tests but...