-
-
Notifications
You must be signed in to change notification settings - Fork 534
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
Consistently perform bootstrap and encode Brotli config for improved caching and reduced code complexity #1836
Consistently perform bootstrap and encode Brotli config for improved caching and reduced code complexity #1836
Conversation
7c0678f
to
3812d56
Compare
cc. @cspotcode. I'm super open to not always go to the child entry-point (when e.g. ESM is not enabled), but I believe this is worth considering as it just makes all of the boostrapping more readable / obvious (while we talk about feature creep and code smell) |
Thanks, I'll have to give this some thought. It's a breaking change to use a child process for all users. It affects PIDs and signal handling and whatnot. And it's a performance regression for users who only need CJS. Some of us in the ecosystem believe that the child process will eventually be unnecessary, once node adds the appropriate features. ...so I kinda want to treat the child process as a hack that's only done when absolutely necessary. To get some of the code quality benefits you describe, I suppose we could pass the brotli payload in-process even when we don't spawn a child. So like, create the payload, and pass it in-memory to the next phase of bootstrapping. That gives us some of the safety and code readability guarantees you describe without imposing the breaking change / perf hit on CJS consumers. |
@cspotcode Yeah, it's trivial to just jump into the final phase in-memory (from the same process). Good points you raised there. I will make this change and rebase the PR. Should be ready for your review/thoughts tomorrow. |
a7c46a4
to
cbdf2c2
Compare
Codecov Report
|
a7e6486
to
6f0ee70
Compare
Only skimming the code, so I may have misinterpreted. But FWIW it's ok to make the breaking change to stop resolving entrypoint relative to our --cwd. Not sure if that simplifies things. |
Also feel free to push a long commit history, no need to force-push if you don't want to. We will squash merge it to |
@cspotcode Thanks for looking. Sounds good. I will not squash the fixup commits (just a habit of other repos). Regarding |
Sounds good. FWIW I'm going to start merging breaking changes to |
Nice! just for your information: This PR is now green and ready for review when you find some time. No rush, thanks! |
Thanks, can I get a quick bulleted list of the changes and their motivation, to assist review? In another comment, or by updating the issue description?
|
@cspotcode This PR:
is this sufficient information?
This is something I'm not sure if worth doing. It would introduce some complexity again, for something that you also acknowledged to be just a workaround in the long-term. I do realize that loading TS is usually a little slow, but is it that big of a deal, people noticing in the meanwhile? Also because it already loads twice if people enable esm in the tsconfig. The complexity will be that we now would also need to pass all |
…caching/reduced complexity Additionally, this PR streamlines the boostrap mechanism to always call into the child script, resulting in reduced complexity, and also improved caching for user-initiated forked processes. i.e. the tsconfig resolution is not repeated multiple-times because forked processes are expected to preserve the existing ts-node project. More details can be found here TypeStrong#1831. Fixes TypeStrong#1812.
…proved caching/reduced complexity Do not use `Nodenext` as `esnext` is sufficent and makes it work with all TS versions we have in the matrix.
44ab40b
to
fbc7754
Compare
…proved caching/reduced complexity Re-add fast-path for ESM when we detect it before phase3. And simplify code.
fbc7754
to
9c0a5a9
Compare
@cspotcode Please find the bullet-point list you requested in the above comment. I also added the fast-path to avoid loading the TS compiler when we detect I also rebased on top of your breaking changes in |
Hey @cspotcode, just wanted to check if there is any way I can help move this forward. No rush, just a friendly check-in |
Friendly ping on this again. Happy to make any changes. also happy to discuss this if this doesn't look reasonable. |
It's been a while. I'm ready to rebase this, or close this, but would like to get it off my plate. Please give an update. |
@cspotcode It's unfortunate that I need to close this— due to no response at all. It would have been totally fine to say that it's not worth the review effort given lack of time etc.. In general- I think the current code in |
Note to self: consider closing #1177 when this is merged, if it does indeed apply to worker threads -- @cspotcode
BootstrapState
for the new approach, removing all the detection flags of whether we are in the CLI.getEntryPointInfo
(coming from the previous ESM fix PR) no longer takes the full bootstrap state. It just fine-grained takes what it needs. This is needed because only the necessary properties/state is cached, so it cannot expect the full parsed arguments (see 2)process.execArgv
. This ensures that phase1-3 do not need to be repeated when forked (and also makes the mental model easy and more expected).execArgv
computation. This logic can be used for settingexecArgv
and for getting the args for going directly frombin.js
into the child process when ESM is needed.index.spec.ts
forking recursiveexecArgv
test had to be updated:execArgv
for ESM (aside from the worker actual fork tests we have)--cwd
but just use the working directory when spawningts-node
(like cd dir && ts-node).