devDependencies are part of the binarySee original GitHub issue
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:
- Install caxa globally with
npm install -g caxa
- Delete the
node_modulesfolder of my project, it seems to be unused by caxa
- Delete the
devDependenciessection in my
- Run caxa as recommended, this seems to cause the installation of all remaining
package.jsonin 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?
- Created 2 years ago
- Comments:7 (2 by maintainers)
Top GitHub Comments
@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
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.
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.