-
Notifications
You must be signed in to change notification settings - Fork 990
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug?]: --fwd doesn't seem to be forwarding anything to dev-server #9209
Comments
Hey @getify thanks for reporting! Yeah our docs could use more clarification, especially since we swapped the default dev server from webpack to Vite in v6. If you just created a Redwood app (looks like it was recent since the version is v6.2.1), then you're using Vite. You'd have to opt back into webpack via the # redwood.toml
[web]
# how to opt back into webpack
bundler = "webpack" While the redwood/packages/vite/bins/rw-vite-dev.mjs Lines 15 to 25 in 9f69fe6
(Perhaps it was meant to be If you're interested in trying to fix the issue, here are the relevant files:
And I'm happy to provide more pointers and ultimately review. And also happy to just implement the fix of course—let me know how you'd like to proceed! Lastly if you'd like to just get things working, you can edit these settings directly in |
I'd definitely like to work on a patch, will take a look. |
Here's what I've figured out so far:
If my analysis is correct, and there's no other magic going on here, then this seems like a fundamental mismatch between the two tools, where one (likely Moreover, the options to Vite's
Ultimately, there's some judgement calls to be made design wise here...
|
@getify great analysis! Yeah there's no other magic going on here. I think this was just left in a half-finished state. And agreed that Just to add more context, when the dev server defaulted to webpack, what I think, in terms of getting this fixed faster at least, implementing the |
OK, I think I understand your intention here. But need a bit more clarification. So... let's say someone ran: In other words,
So first question: which of these (or all?) do we want to support? Is there any reasonable justification for only supporting forwarding some of these? Next question: are we going to create individual flags (in If we're doing individual flags, should we follow some naming convention for these individual flags, like Or if we don't want to do individual flags (perhaps because that's too many?), should we instead have folks provide a single JSON-like object, at a param like |
For sure; I should emphasize that the main driver behind my design decisions at the moment is how to fix this as fast as possible for you while not locking us out of a proper long-term solution. I think the long-term solution is swapping out If you're not concerned with getting a fix this week, then I can stop thinking that way and suggest that we think about swapping out But to keep answering your questions with my current line of thinking, the justification for only supporting forwarding some flags is 1) I only have anecdotal data, but those three flags (open, port, host) are by far the most common. And 2) if we support forwarding them all, we should really just do the right thing and swap out Answering your next question, yeah redwood/packages/vite/bins/rw-vite-dev.mjs Lines 22 to 25 in 083c048
I.e., Lastly I'd push back against the And sorry this is somewhat confusing haha, I didn't do the work here so I can only make guesses at intention. So appreciate you bringing this up and discussing it with me! |
Adds 2 debug configurations to vscode/launch.json - Web Debugger (launches the built-in chrome web debugger) - Compound of Dev + Api + Web (launches a fully debuggable redwood with a single configuration) It makes sense to disable the browser open in the redwood.toml if you want to use the web debugger alone or in compound. ``` [browser] open = false ``` It'd also be possible to add a --fwd="--open=false" but that is currently being discussed as an issue in #9209 --------- Co-authored-by: Tobbe Lundberg <tobbe@tlundberg.com>
Adds 2 debug configurations to vscode/launch.json - Web Debugger (launches the built-in chrome web debugger) - Compound of Dev + Api + Web (launches a fully debuggable redwood with a single configuration) It makes sense to disable the browser open in the redwood.toml if you want to use the web debugger alone or in compound. ``` [browser] open = false ``` It'd also be possible to add a --fwd="--open=false" but that is currently being discussed as an issue in #9209 --------- Co-authored-by: Tobbe Lundberg <tobbe@tlundberg.com>
this turns it off for everyone, not just codesandbox. but the cli doesn't currently properly forward vite props (redwoodjs/redwood#9209) at the moment
What's not working?
I consulted the docs here: https://redwoodjs.com/docs/cli-commands#dev
They mention using the CLI flag
--fwd=" ... "
to send along flags that control the underlying dev server (webpack I guess?).In particular, I wanted to:
I issued this command:
yarn rw dev web --fwd="--no-open --port=9234 --allowed-hosts=all"
Also tried this variant:
yarn rw dev web --fwd="--no-open --port 9234 --allowed-hosts all"
(spaces instead of
=
)None of the 3 flags seem to affect anything, as the browser still opens, the port is still
8910
, and I still can't hit the dev-server instance from my phone using my laptop's local LAN IP.SIDE NOTE: the docs linked above still say to use
--open=false
for stopping the browser from opening. I tried that, first. But then I found another issue saying that the underlying webpack arguments had changed to--no-open
. Docs should be updated there.To be clear, though, the webpack docs do still say that
--allowed-hosts all
should be working, but it doesn't seem to be, as I don't think any of those params are getting forwarded (as I asserted above).How do we reproduce the bug?
Try the above command(s) as I mentioned.
What's your environment? (If it applies)
System: OS: Linux 5.15 Debian GNU/Linux 11 (bullseye) 11 (bullseye) Shell: 5.1.4 - /bin/bash Binaries: Node: 19.9.0 - /tmp/xfs-c4e108ca/node Yarn: 3.6.1 - /tmp/xfs-c4e108ca/yarn npmPackages: @redwoodjs/core: 6.2.1 => 6.2.1
Are you interested in working on this?
The text was updated successfully, but these errors were encountered: