Use `yarn --production` instead of `npm dedupe --production`
Closed this issue · 6 comments
Hi,
caxa looks great - thanks! It seems a bit slow to start the application (on Windows). I'm not sure why (may be Defender). But that's quite another story.
The ready-built package will contain a package-lock.json
, which may collide with using yarn (apart from enlarging the package). Apparently the file is created by npm dedupe --production
.
npm dedupe
also recreates node_modules which are intentionally removed with yarn PNP.
So caxa could support another commandline option (like --yarn) to run yarn --production
instead of npm dedupe --production
.
Edit: so well, with yarn3 yarn --production
should not be used as it seems - instead it's more complicated: https://yarnpkg.com/cli/workspaces/focus
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.
Yes, works for me (--no-dedupe
though).
The command line is rather long now (even with short parameters), but doesn't seem to matter.
Great. I’m glad you got things working.
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.
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:
-
Use
--exclude
to avoid copying stuff you don’t want into the temporary directory, for example,.git
. -
Use
--prepare-command
as<commands-that-you-want-to-run> && rm <files-that-were-generated-by-the-previous-commands>
.
How does that sound?
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.