Skip to content
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

UX Bug in wrangler dev #308

Closed
Warfields opened this issue Jan 26, 2022 · 9 comments
Closed

UX Bug in wrangler dev #308

Warfields opened this issue Jan 26, 2022 · 9 comments
Labels
polish Small improvements to the experience

Comments

@Warfields
Copy link
Contributor

Warfields commented Jan 26, 2022

The prompt box for wrangler dev's tools is a bit glitchy as seen below

Screen Shot 2022-01-25 at 10 06 29 PM

How to reproduce

  1. wrangle dev <wrong_path_to_src>
  2. repeatedly press L

asciicast

@Warfields Warfields added bug polish Small improvements to the experience labels Jan 26, 2022
@Warfields
Copy link
Contributor Author

Warfields commented Jan 26, 2022

This appears to only be an issue when you mistype the path, not sure if we even should care about this now. Previously I thought it always appeared when starting and stoping miniflare.

Screen Shot 2022-01-25 at 10 11 06 PM

@threepointone
Copy link
Contributor

If we have a wrong path to src, we should simply quit the process with an error message. (We should do the check after useCustomBuild returns in dev, and after running config.build.command in publish, because that may be the logic that generates the file).

@threepointone
Copy link
Contributor

Ok, I see we fail for publish, but in dev we just catch the error and leave the process running. We should end the process immediately.

@Warfields
Copy link
Contributor Author

I looked into the code and found this, it appears that we caught the build errors for a reason. I think it's so that when --watch is used we don't immediately kill the process, we could add a conditional if watch is not present to kill on line 507.

@Warfields
Copy link
Contributor Author

Further digging, by default the code uses --watch on all ESBuilds. So we might want to watch for the not resolving error specifically, but I am not sure if a file with an error in it would raise the same error.

@petebacondarwin
Copy link
Contributor

Is an invalid entry-point unrecoverable? I.e. what if we renamed the entry-point (causing the build to break) and then renamed it back again? If so, then perhaps we should not exit but instead just make sure that the UI doesn't get corrupted.

@Warfields
Copy link
Contributor Author

Warfields commented Jan 26, 2022 via email

@threepointone
Copy link
Contributor

It's very unlikely that an entry point would get renamed. We can work on that usecase, but seems like overkill to design around that. In this scenario, it doesn't exist on the first run itself, and we should probably exit immediately imo.

@Electroid Electroid added this to the 2.0 milestone Feb 3, 2022
@Electroid Electroid moved this to Non-blocking in workers-sdk Feb 7, 2022
@threepointone
Copy link
Contributor

Fixed by #455

Repository owner moved this from Should-have to Done in workers-sdk Feb 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
polish Small improvements to the experience
Projects
None yet
Development

No branches or pull requests

4 participants