✅ Deploy Preview for creative-fairy-df92c4 ready!

Name	Link
🔨 Latest commit	065435d
🔍 Latest deploy log	https://app.netlify.com/sites/creative-fairy-df92c4/deploys/65b7dacc66a5e70008c2d7db
😎 Deploy Preview	https://deploy-preview-378--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 site configuration.

I don't want to include .env files in the ZIP... They usually contain secrets that shouldn't be shared.

Instead, we should include a new option, zip.include, where people can setup files they want to include in the zip in addition to the default files.

Alternatively, we could ignore .env files while running pnpm zip. This solution doesn't sit well with me, since sometimes .env files are used to configure the actual build.

This is less of a problem when building in CI, where .env files are generally not present, but could still potentially be a problem there too.

I am not sure is there a way to contact you somehow? Maybe Discord?

Hmm, I have a discord, but I don't have notifications on, and I haven't opened it for 2 years. I don't like being overran by notifications. I'd prefer just starting a discussion on github, but maybe I should make a discord channel for WXT, it's pretty common for libraries to do that...

I'd like to learn if there's an easy way to test the source changes locally?

The easiest way to test the app is by recreating the issue in the demo/ folder, and testing there. Once it's working there, to test in a real project, I run pnpm pack to get a tarball, then I copy it into the project, and install the tarball.

Hmmm, is there part of WXT that can be used for server-side parts? If not, I do not see a problem of an .env being zipped for review team, since it all ends up bundled in the code anyways.

Even if there was a scenario that someone would commit the .env file to the repo, if it's all client-side code, it's not considered a secret.

Even if there was a scenario that someone would commit the .env file to the repo, if it's all client-side code, it's not considered a secret.

@dvlden I use .env files to store default login credentials for development, like a GitHub personal access token:

https://github.com/aklinker1/github-better-line-counts/blob/552a0db045fbf0159bb13e068938c65dc9feff74/src/utils/storage.ts#L22-L24

Ouch, I see... In that case, your idea to have includes as an option sounds good to me.

Let me know if this is something that you'd let me try to implement? Cause it's similar to excludes, just opposite.

Yeah, if you want to give it a go, that'd be great!

I did not come across any tests for this? I thought it may break, since I renamed ignoredSources, but no failing tests.

Where do I update documentation? Is that inferred from DocBlock?
EDIT: Nvm just read the CONTRIBUTING.md

What do you think about it? I tested in demo dir and my project and it seems to work.

Codecov Report

Attention: 10 lines in your changes are missing coverage. Please review.

Comparison is base (62ecb6f) 80.41% compared to head (065435d) 80.34%.
Report is 4 commits behind head on main.

@@            Coverage Diff             @@
##             main     #378      +/-   ##
==========================================
- Coverage   80.41%   80.34%   -0.08%     
==========================================
  Files         104      104              
  Lines        7528     7552      +24     
  Branches      681      682       +1     
==========================================
+ Hits         6054     6068      +14     
- Misses       1458     1468      +10     
  Partials       16       16              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Nice, thanks 👍 I'll get this released soon.

Glad to be of any help. Looking forward to more contributions. If you get something that you think I could resolve in this large project's codebase, feel free to assign me.

Really need this to get through Firefox approvals.