-
-
Notifications
You must be signed in to change notification settings - Fork 26
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
V3 #96
Conversation
- Installer and patch rewritten and compile - Not fully tested - Needs tests
- Set cache dir to node_modules/.cache convention - Fixed almost all open issues - Got patch working - Got tspc working - Fixed broken .editorconfig
- Fixed cache - Speed optimizations - Added "live" modules (tts replacement) - Added perf testing script - Fixed bugs
Responding to @jakebailey:
I definitely understand where you're coming from. I agree that this would been the ideal route to go for simply maintaining what we were doing. I chose the current approach in view of the upcoming next version of tsp, which will be much more versatile, essentially allowing multi-faceted plugin packages. The changes in the latest TS sort of forcibly incentivized me to write the foundation for that sooner. The short version is, you'll be able to bundle language service plugins and transformers in addition to two new features, which are middleware "hooks" and compiler transformers. The latter are applied at patch time on the compiler code itself. This should open up some unique opportunities, which I'm excited to explore. For that reason, we needed to find an approach that made the most sense and could perform well. Having clearly defined boundaries via comments made this much more realizable, though I understand they're not guaranteed for future versions — more on that below. What we have now are "slicers" and "patchers" associated with each TS version. Slicers run through and identify common points that we need to know (ie, file header, body wrapper start, body header, etc.) These points are then used with memoizing so that we only ever create a SourceFile for the section of code that we know we need to transform. This approach had tremendous perf gains over simply creating an initial SourceFile. Notably, we're also using caching, so most patching operations (after first run of a config state) should be faster than a yarn patch. One disclaimer I should say about the current branch is that the organization is still not what I'd like it to be. It's a little messy and what's there is still largely an artifact of the exploratory process. It will be much cleaner, better organized, and its components more clearly defined as we move forward. This is a sort of alpha structure for what will come, that resembles something like what will be under the hood of the next.
Fortunately, the order won't matter. Slicers create a basic file map, keyed by filename.
With regard to this or any other potential changes, I definitely recognize that this is all subject to change. There is always some level of that which is to be expected. With that in mind, I crafted the approach to minimize as much potential of it as possible, while also aiming to make it easy to accommodate future versions if and when changes do happen. Although current file structure doesn't reflect it, the idea is to likely make new sets of slicers and patchers on an as-needed basis. Mostly, we'll just need to update a few transformers if things change and if something moves, we tell it to look in a different SourceFile. Overall, I think the gains in performance and targetability to original source files are worth the risk of changing tracking for a moved function from time to time. That said, users will have the option to apply transformers at a global SourceFile level, if they prefer. We'll also want to have CI keep up with dev builds on a specified interval so we can stay ahead of changes. One thing that would be great, though, would be if we could maintain the output of comment headers for the compiled files in the built TS libraries. Having that guarantee on those boundaries brings a major performance boost and would be more reliable than the previous method of using regex search for a particular declaration, block, etc. If your side is open to that, I would be happy to contribute to ensure that's done for any future changes to the build process (like if you switch from esbuild), so it doesn't put any added burden on the TS team. Any other thoughts you have, I welcome the discussion, and I appreciate your taking the time to weigh in as well as to let me know about the previous conflicts ahead of time! |
- Circular program transformer - added esModuleInterop by default - Fixed issues with require & improved logic
I'm getting heap overflows using 3.0.0-beta3 |
@bennypowers can you make sure that it isn't rc2? Beta3 should be stable, but rc2 has that issue. |
Thanks @nonara for the response. Inspecting the npm package I see that rc2 is a later version than Thank you again for the response, and for your hard work on this upcoming release. |
Got the same heap overflow issue with rc2 that is fixed by using beta3. Please let us know if you'd like us to test it again with a newer version. |
Happy to help! I'll be fixing it and doing full release soon. Been going nonstop with work obligations for weeks now. Should be back to normal after next week. Meanwhile beta3 should work. |
Can I ask how you are these days? |
…gin config option
Added PR to fix current console bug: #100 |
I finally had a few days to sit down and dedicate toward this. The current version should be working in all scenarios. I'm including some notes here, if anyone is interested / for posterity. IssuesLong story short, there were several big issues that made this more complex than it appeared. The top things that contributed to this was my trying to drop the need for ts-node and to implement ESM support. The following are a few details on the challenges
|
@samchon Doing well, thanks. I tested this with typia and it appears to work. I'm not doing a beta / rc release for this one, so if you'd like to check, you can clone this branch and give it a try. Let me know if you have any issues or comments. I will be releasing full version directly, but I'm going to build out tests and make sure it's fully covered first. |
@nonara Thanks for your dedications. I'd tested in both As you can see from above github actions, there had not been any problem. |
ts-patch install
#75)