chore: Add example of env usage to wxt-demo

[PatrykKuniczak]

Overview

I've added a little example, how to use env in code, here background was used

I want to add this, because it can be quicker to take a look in code(during initial run, e.g as a new maintainer), than checking it in docs :)

[netlify]

✅ Deploy Preview for creative-fairy-df92c4 ready!

Name	Link
🔨 Latest commit	049a480
🔍 Latest deploy log	https://app.netlify.com/projects/creative-fairy-df92c4/deploys/698a541145b29e0008d57ec6
😎 Deploy Preview	https://deploy-preview-2108--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.

[pkg-pr-new]

Open in StackBlitz

@wxt-dev/analytics

npm i https://pkg.pr.new/@wxt-dev/analytics@2108

@wxt-dev/auto-icons

npm i https://pkg.pr.new/@wxt-dev/auto-icons@2108

@wxt-dev/browser

npm i https://pkg.pr.new/@wxt-dev/browser@2108

@wxt-dev/i18n

npm i https://pkg.pr.new/@wxt-dev/i18n@2108

@wxt-dev/module-react

npm i https://pkg.pr.new/@wxt-dev/module-react@2108

@wxt-dev/module-solid

npm i https://pkg.pr.new/@wxt-dev/module-solid@2108

@wxt-dev/module-svelte

npm i https://pkg.pr.new/@wxt-dev/module-svelte@2108

@wxt-dev/module-vue

npm i https://pkg.pr.new/@wxt-dev/module-vue@2108

@wxt-dev/runner

npm i https://pkg.pr.new/@wxt-dev/runner@2108

@wxt-dev/storage

npm i https://pkg.pr.new/@wxt-dev/storage@2108

@wxt-dev/unocss

npm i https://pkg.pr.new/@wxt-dev/unocss@2108

@wxt-dev/webextension-polyfill

npm i https://pkg.pr.new/@wxt-dev/webextension-polyfill@2108

wxt

npm i https://pkg.pr.new/wxt@2108

commit: d9908e8

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.08%. Comparing base (cc849e7) to head (049a480).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2108      +/-   ##
==========================================
- Coverage   76.11%   76.08%   -0.04%     
==========================================
  Files         113      113              
  Lines        3027     3027              
  Branches      679      679              
==========================================
- Hits         2304     2303       -1     
  Misses        640      640              
- Partials       83       84       +1     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[PatrykKuniczak]

OH EACH tests.
@aklinker1 Let's tell me if you want to remove it from tests and use my func, or what should i do with it?

[aklinker1]

This is "runtime config", not "env".

That said, what is the meaningful change this PR adds? We're already logging the runtime config on line 16 of the background script, and there's plenty of examples of env vars via import.meta.env.

In other words, what did you add that wasn't already there?

I like cleaning up all the duplicate logs for the extension ID, that can stay for sure.

As for uppercasing EXAMLE, regular camel case is convention for runtime config property names. Notice how none of vite's or wxt's config are snake case - runtime config is the same. You can upper case it if you want in your own projects, but WXT's docs and examples need to be consistent.

[aklinker1]

I don't want to waste your time, so let me be clear about these refactors: they need to have a valid reason behind a change.

If you're just shuffling code around, or adjusting format/whitespace according to your own opinion, or trying to change the entire project's standards (like uppercasing tons of variables in tests), I'm not going to approve those changes.

They're not meaningful changes that makes the codebase better. Like I said, I have lax linting rules, so if you're changing style just because you like it better, but it was already passing lint... What's the point? According to the repo's rules, the code was valid before.

I'm open to large refactors, but ask permission first so we don't waste each other's time, be comprehensive, and understand the code you're making changes to.

For example this PR:

• ✅ Small enough you don't need to ask permission, perfect!
• ✅ There are some valid changes here! Like removing duplicate logs and showing the runtime config is available in all entry points.
• ❌ you didn't understand the difference between env vars and runtime config
• ❌ You missed that we were already logging runtime config in the background - why add a second example of accessing it?

I apologize if I seem up-tight about this and generally against some of your PRs and comments - but you did come in and make sweeping changes, introduced bugs, and changed standards I already had set in one massive PR that was too large to review. Your second PR around refactoring the docs also changed a lot of things, mixing in CSS cleanup, formatting changes, and bug fixes.

So hopefully you can see things from my point of view, that I'm a bit cautious of your refactor PRs at this point - I don't view them as safe to merge, and it's taking a ton of my time to review them.

I'm not saying there aren't code quality improvements to be made - you saw my 10 PRs I pulled out from your PR. They were good changes, and I made sure to add you as a co-author on all of them. If you read their descriptions, I explain why I decided each on was valid.

Other than one off changes I missed... I don't want to merge any of your original refactor PR. It seemed like you just had an InteliJ editor auto-fix a bunch of stuff with no context of the project...

To finish things up: I am excited to be working with you and want you to be motivated to contribute. I think a better way of onboarding you into the project and get used to working with me would be to work on some feature requests instead of refactors. Build something with immediate value, get used to the codebase's existing style so you have a better understanding of what is inconsistent or what could be cleaned up in a minimal but useful way.

So, with that in mind, could you work on #1029? It would be a killer feature to have in WXT 👊

[PatrykKuniczak]

This is "runtime config", not "env".

Yeah, that was late late night, and i've recognized it today, after i've woke up, and browser.runtime.id shouldn't be removed, because it isn't related to env

[PatrykKuniczak]

@aklinker1 I've missed this console.log(useAppConfig());
This PR is unnecessary, indeed, if i've recognized it i won't open it.

[PatrykKuniczak]

I apologize if I seem up-tight about this and generally against some of your PRs and comments - but you did come in and make sweeping changes, introduced bugs, and changed standards I already had set in one massive PR that was too large to review. Your second PR around refactoring the docs also changed a lot of things, mixing in CSS cleanup, formatting changes, and bug fixes.

Don't apologize, that's your project, i'm some kind of impostor here, and only person, which can apologize is me, because i'm wasting your time, not opposite.
I've missed this console.log(), i'll try my best to not open PRs like this in the future.

[PatrykKuniczak]

So, with that in mind, could you work on #1029? It would be a killer feature to have in WXT 👊

I preffer to take one of bug for now, because i won't have much time in the near future, but i'll be able to take it some day.
Only thing i need to know now.
Are you want me to open PRs with new types instead of any from #2022?
I'm able to split it into smaller PRs and this will be last thing from current refactor.

[PatrykKuniczak]

@aklinker1 I'm able to close work on current PRs, including new one with new types(If you'll be interested)
Then i'll be less active, that's why i want to close it ASAP.

After this week i'll pick one old bug issue or sth like that and i'll try to solve it in free time, i hope you'll like this :)

[aklinker1]

A bug is a good place to start as well! Thanks for understanding.

Are you want me to open PRs with new types instead of any from #2022?

🤷 I remember a few changes that would be valuable, if you're confident, go ahead and open a PR.