Support yarn zip dependencies

[rightaway]

Yarn 2 and 3 let you replace node_modules with each dependency being a single zip file. It's much cleaner and makes for faster installation, fewer files, and less space used in development. You can also check them in to source control unlike node_modules. Since yarn is quite popular it would be good to support the use of these zip dependencies as an option.

[jeffrson]

It somewhat works with

yarn caxa -N -D -e .git -e app.exe --input . --output app.exe -- "{{caxa}}/bin/node" "{{caxa}}/.yarn/releases/yarn-3.2.0.cjs" node "{{caxa}}/index.js"

where {{caxa}}/bin/node.exe is the node-Version of your choice.

It's not easy to trim dependencies to production (yarn cache clean && yarn workspaces focus --production), and even then it seems to be more than with npm.

[leafac]

Hi @rightaway,

As @jeffrson pointed out, caxa offers several command-line flags to customize what will happen to your application as it’s being packaged. Do you think you can get what you want using them?

Best.

[rightaway]

@jeffrson caxa looks in node_modules for dependencies, but it will only find zip files so it will fail but I think it could be supported because of the benefits of using zip files for dependencies.

[leafac]

🤔 What do you mean by “caxa looks in node_modules for dependencies”? You can use options such as --no-dedupe (and others, check the documentation) to disable any behavior specific to npm. At that point, caxa shouldn’t be touching dependencies at all.

[rightaway]

I see that the readme says caxa doesn't traverse require() calls. I thought it did and that it would be a problem if when traversing require() it would find a zip file not a directory. How does caxa create the bundle without the traversing magic?

[leafac]

I see that the readme says caxa doesn't traverse require() calls. I thought it did and that it would be a problem if when traversing require() it would find a zip file not a directory. How does caxa create the bundle without the traversing magic?

Please check out this section of the documentation: https://github.com/leafac/caxa/tree/5576fce37065ae06d7f1da3e2bceec13a9f433f9#how-it-works

Can you please test caxa with the zipped dependencies and confirm that it works before we close the issue?

[rightaway]

I read that part of the documentation it's interesting. When you extract the self extracting caxa archive does it contain the same original text files and directory tree layout as what is in the source tree you ran caxa on?

What would be there when you extract the self extracting archive after V8 snapshots will be implemented #21? How would using those snapshots help hide the code? We would like to switch to caxa from pkg but need to wait until it can hide the code like pkg does.

Can you please test caxa with the zipped dependencies and confirm that it works before we close the issue?

I haven't switched to yarn 2 or 3 yet. But I'll close this since I didn't know caxa doesn't traverse require() and if it fails for anyone it can be reopened.

[leafac]

When you extract the self extracting caxa archive does it contain the same original text files and directory tree layout as what is in the source tree you ran caxa on?

Yes.

What would be there when you extract the self extracting archive after V8 snapshots will be implemented #21?

The feature hasn’t been implement, so I don’t have a definitive answer to that. But I know that it’ll be enough to hide the JavaScript source of your program. I think that this is actually the main reason why people are interested in V8 Snapshots—probably the startup performance difference is negligible.

How would using those snapshots help hide the code?

As far as I understand V8 Snapshots amount to the same as a compiled binary in other languages like C++ in the sense that it becomes difficult to reverse engineer. For example, compiler optimizations are baked in, and that sort of thing.

We would like to switch to caxa from pkg but need to wait until it can hide the code like pkg does.

As far as I understand V8 Snapshots are what pkg uses, so you may interested in contributing to #21 to get us there. In the meantime, you may experiment with JavaScript obfuscation tools. Some people reported success with that…