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

Use tsx for scripts and local admin server #3550

Merged
merged 2 commits into from
May 14, 2024
Merged

Use tsx for scripts and local admin server #3550

merged 2 commits into from
May 14, 2024

Conversation

rakyi
Copy link
Contributor

@rakyi rakyi commented Apr 30, 2024

This improves the DX significantly when running admin locally. Admin server restarts faster and client hot reload doesn't end in a network error. TS errors don't block running the code.

We can also run many scripts locally with the TS source directly instead of using the compiled output from itsJustJavascript. The remaining reasons to keep using it for some cases are:

  • tsx doesn't work with Jest OOTB, our best bet is probably to switch to Vitest
  • Compiling the code separately before running it in prod is safer and should be more performant, especially for long-running processes

@rakyi rakyi force-pushed the tsx branch 2 times, most recently from 0f3614a to 269de19 Compare April 30, 2024 11:52
@rakyi rakyi marked this pull request as ready for review April 30, 2024 13:03
@rakyi rakyi requested a review from marcelgerber April 30, 2024 13:16
@rakyi rakyi changed the title Use tsx for scripts and local env Use tsx for scripts and local admin server Apr 30, 2024
Copy link
Member

@marcelgerber marcelgerber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, this works really well and makes the dev experience lots better!

The only difference in behaviour I could make out is that, after an uncaught exception, the dev admin server doesn't automatically restart. Try going to http://localhost:3030/admin/charts/0/edit, for example, which will throw an exception and make the admin server crash.

I think it's fine to acknowledge this difference in behaviour for now (as it is also the way I found out that this exception is actually uncaught), and to let devs know that by hitting "Enter" in the tsx process, they can restart the process.
And if it becomes too annoying at some point, we can still consider how else we can solve this.

@rakyi
Copy link
Contributor Author

rakyi commented May 13, 2024

I'm not sure what is causing the difference in behavior, since tsx is claiming to behave the ~same as node. But I'm surprised the server restarts/recovers with your example error in master, since we are clearly not handling the errors and the server should crash in that case too.

When I tried handling the error properly, we get 404 in the browser instead of unhandled 500 and the server doesn't crash with tsx.

The proper solution then seems to be to handle the errors correctly. Do you know why we currently don't?

@rakyi
Copy link
Contributor Author

rakyi commented May 13, 2024

Rebased on master.

@owidbot
Copy link
Contributor

owidbot commented May 13, 2024

Quick links (staging server):

Site Admin Wizard

Login: ssh owid@staging-site-tsx

SVG tester:

Number of differences (default views): 42 (978dd4)
Number of differences (all views): 150 (31de2e)

Edited: 2024-05-14 19:01:12 UTC
Execution time: 1.20 seconds

@rakyi
Copy link
Contributor Author

rakyi commented May 14, 2024

After discussing with Daniel, we decided I'll add the missing error handling to async functions.

@rakyi rakyi merged commit 9b4d68a into master May 14, 2024
21 of 25 checks passed
@rakyi rakyi deleted the tsx branch May 14, 2024 19:02
@marcelgerber
Copy link
Member

I'm not sure what is causing the difference in behavior, since tsx is claiming to behave the ~same as node. But I'm surprised the server restarts/recovers with your example error in master, since we are clearly not handling the errors and the server should crash in that case too.

I guess it's because we were using tsc-watch - in particular, yarn run tsc-watch -b --onSuccess "yarn startAdminServer" in this case.
While their docs don't say anything about restarting after a crash, I guess that's what they are doing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants