feat: Add option to strip workspace: protocol from dependencies in zipped sources

[darthmaim]

Overview

This adds a new option zip.stripWorkspaceProtocol to strip the workspace: protocol from dependencies when zipping the sources. All package managers except npm do this when publishing packages¹, and since creating the zip is a form of publishing, wxt should do the same.

This is an option defaulting to false, as some people zip monorepos using sourcesRoot: '../..', or similar, where the workspace: protocol should be kept.

Note that this only strips the prefix for now (so workspace:* becomes *, instead of replacing *, ^ and ~ with the version defined in the workspace like the package managers do.

Manual Testing

Create a new extension in a monorepo depending on a workspace dependency, and then create the zip using wxt zip -b firefox. Check the generated package.json in the sources.zip.

I was sadly not able to write a e2e test for this, as all the tests run with --ignore-workspace added at various points. Maybe the e2e tests could be improved to create the projects in a path outside the wxt repo (maybe /tmp/wxt-e2e/<id>, instead of e2e/dist/<id>, so scenarios using workspace could be tested.

Related PRs

• fix: Correctly zip local (and aliased) packages #1685

Footnotes

1. Here is the documentation of the different package managers on how they handle workspace:: pnpm / yarn / deno / bun ↩

[netlify]

✅ Deploy Preview for creative-fairy-df92c4 ready!

Name	Link
🔨 Latest commit	6059387
🔍 Latest deploy log	https://app.netlify.com/projects/creative-fairy-df92c4/deploys/6839b058b01da20008da5b9f
😎 Deploy Preview	https://deploy-preview-1689--creative-fairy-df92c4.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[PatrykKuniczak]

@darthmaim Are you interested go on with this?

[darthmaim]

Sure, if there is some interest to add this to wxt I'd be willing to look into working on this again.

[PatrykKuniczak]

@darthmaim Thanks for quick answer, but this question need to be redirect to @aklinker1, because he wasn't gave here any answer.

You need his approval, then you'll be able to go on with this, i only want to not let die this PR and your interest 😄

[aklinker1]

Thanks for the ping.

I guess I'm confused why this is necessary. If you're using a monorepo... just include the monorepo in the zip, have Firefox use the monorepo to build your extension with the correct package manager, and everything will work. The download packages feature is meant for private packages hosted with authentication that you don't want to provide to Firefox, not linking to local ones.

Could you elaborate around in what cases this is necessary? Or maybe show a real world use-case for this? Is it just to obfuscate more of your code from the reviewers?

[darthmaim]

I just have a big mono-repo including multiple servers and other apps, and just the simple extension source + 2 small packages are needed to build the extension. I don't think it should be required to pack the entire monorepo just to build 3% of the code. Yes, I can include/exclude unrelated files in the zip, but then I have to keep the config up-to-date when changing other packages. And I also might have to include additional packages to build the dependencies (if the build scripts even work with missing packages).

Imho building the extension source zip should work like pnpm deploy (and I might just use that one day and pack the extension from the deploy output).

[aklinker1]

I'd rather not be responsible for maintaining this. Package managers already handle this, I don't think WXT needs to duplicate their code.

I understand it might be annoying to manually include/exclude files in a monorepo when your extension is a small part or it, but we have an improvement coming soon that should simplify this. See #2114