devDependencies are part of the binary

@leafac What a cool project! Thank you very much for your work on this. Once ARM support is ready it is a very interesting alternative to pkg although the source code is not hidden and must be evaluated first.

After some tests with my project on Linux I found out that all of my devDependencies are part of the resulting binary (file size is ca. 42 MB, ca. 160 MB after extraction). In the README you write:

You don’t need to npm prune --production and npm dedupe, because caxa will do that for you from within the build directory. (Otherwise, if you tried to npm prune --production you’d uninstall caxa, which should probably be in devDependencies.)

but this seems not to be the case for me. My current workaround:

1. Install caxa globally with npm install -g caxa
2. Delete the node_modules folder of my project, it seems to be unused by caxa
3. Delete the devDependencies section in my package.json
4. Run caxa as recommended, this seems to cause the installation of all remaining dependencies from package.json in the build directory of caxa.

Now, I get a working binary with file size of ca. 15 MB (ca. 39 MB after extraction). The result is impressive. Is there something wrong with this approach to avoid the devDependencies?

[fcastilloec]

@leafac After further testing, I’ve realized that npm dedupe reinstalls all dependencies including all devDependencies, undoing what npm prune --production did. A simple fix to this issue would be to just remove this line https://github.com/leafac/caxa/blob/master/src/index.ts#L31. Or at the very least run prune after dedupe and not before.

PR #8 could also fix this issue, but I think that PR is targeted at introducing a new feature rather than fixing this issue. It just happens to fix this issue as a side effect.

[iCrazyBlaze]

This is happening to me on Windows. Caxa itself, along with other stuff specified in devDepenencies is being packaged into the final binary. npm prune --production doesn’t seem to be making a massive difference.