Use `yarn --production` instead of `npm dedupe --production` about caxa

[leafac]

Hi @jeffrson,

Thanks for the nice words and for reaching out.

Do you think you could make things work with the --dedupe and the --prepare-command command-line flags?

Best.

[jeffrson]

Yes, works for me (--no-dedupe though).

The command line is rather long now (even with short parameters), but doesn't seem to matter.

[leafac]

Great. I’m glad you got things working.

[jeffrson]

@leafac

Unfortunately I wasn't right.

Although everything seemed to be fine, it isn't:
--prepare-command and --exclude don't work well together. I exclude files from .yarn (eg .yarn/cache), which, however, are instantly recreated by the prepare-command I want to use.

So I think, the order of exclude and prepare should be switched, which, btw, sounds quite sensible: first prepare, then do all other things.

[leafac]

Oh, interesting. It seems like you and I understand the point of --exclude differently:

You: --exclude means “don’t include this file in the binary.”
I: --exclude means “don’t copy this file over into the temporary directory where the application will be prepared.”

Your --exclude comes late in the chain of processes that need to happen to make an executable. Mine comes early.

That’s a miscommunication that I’ll address in the documentation.

In light of this information, I suppose that you still can get what you want by using the existing configuration facilities in caxa:

1. Use --exclude to avoid copying stuff you don’t want into the temporary directory, for example, .git.

2. Use --prepare-command as <commands-that-you-want-to-run> && rm <files-that-were-generated-by-the-previous-commands>.

How does that sound?

[leafac]

Hi @jeffrson,

Thanks for using caxa and for the conversation here.

I’ve been thinking about the broad strategy employed by caxa and concluded that there is a better way to solve the problem. It sidesteps the issues of --include and --exclude entirely. Can you please give it a try and report back? I don’t have any experience with package managers other than npm, so maybe you can help in that department.

It’s a different enough approach that I think it deserves a new name, and it’s part of a bigger toolset that I’m building, which I call Radically Straightforward · Package.

I’m deprecating caxa and archiving this repository. I invite you to continue the conversation in Radically Straightforward’s issues.

Best.