PR that converts the TypeScript repo from namespaces to modules
github.com
github.com
Surprising they call out the 2 space indent level that esbuild is hardcoded[1] to use as a benefit. Why not save even more bytes and re-format the output to single tab indentation? I wrote a simple script to replace the indentation with tabs. 2 indent size: 29.2MB, tabbed size: 27.3MB. 2MB more of indentation saved! Not significant after compression, but parsing time over billions of starts? Definitely worth it.
For your answer search "programmers who use spaces make more money"
This is the exact reason that crime statistics are so crummy, even from anonymous surveys. Very few are compelled to admit to a crime that they haven't been convicted of (and some won't even to admit to that). Or why post-sale NPS scores have a negative bent - you're more likely to respond if you have a complaint.
Spaces are simply inferior to tabs since the latter conveys the meaning of "one level of indentation" while the former does not. It's also better for accessibility and file size. There is not one single logical reason to ever use spaces for indentation, not one.
For some very fucking stupid historical reason someone in the 80s made the idiotic decision of spaces being the default in editors and people just went with it. The people earning more are doing so because those are the seniors who have given up on common sense and just go with the flow of the masses who are unable to grasp "tabs for indentation, spaces for alignment" yet insist on keeping alignment so the (terrible) compromise is just using spaces. And I strongly question whether "alignment" is worth anything, in almost all cases it's just useless and in the rest you're drawing ASCII diagrams in the comments which doesn't affect your code at all.
Also see the top answer at https://www.reddit.com/r/programming/comments/8tyg4l/why_do_...
I think you wrote this the wrong way around?
What I think gp is underestimating is just how much alignment there was in the old days, and how little (compared to now) indentation. From today's perspective, indentation is the norm and alignment is the rare exception. Your question is a good illustration: sounds like you never met alignment, or at least never noticed it. But back then, alignment was a very regular occurrence and the extra diligence required for getting all the tabs and blanks right to look nice on different tab widths, or the ugliness from failing to get the mix right would have been a considerable cost. Avoiding unpredictably wide tabs was a reasonable call.
Thing is that with spaces you can also predict consistently the line length and not have code being clipped on someone's screen that set tabs for 8 spaces for some reason.
In any case, I like spaces but I am impartial to either one. You seem like you have very strong opinions about the matter so I won't push the subject further.
> Thing is that with spaces you can also predict consistently the line length and not
> have code being clipped on someone's screen that set tabs for 8 spaces for some reason.
But I'm also the crazy person who uses an 8 wide indent anyway
I like four character width indentation. Linus prefers eight. With tabs VIM shows me what I like and shows Linus what he likes.
As an interesting note, I now work with the second hard-of-sight developer that I've worked with in my life. They both use normal Jetbrains IDEs, with font sizes and interfaces made huge. Neither of them has ever said a word about my line length. Nor my function length. Nor my long variable and method names. Nor my explicit comments, nor my detailed git commit messages, nor my frequent git commiting, nor my branching preferences, nor my README files, nor my obsessive security practices such as validating types and character length limits on input fields and sanitizing and filtering input and my rejecting of any PR with concatenated outside-data in SQL (even if that outside-data came from the DB itself, for a recent example), and all the other idiosyncrasies that one dev suffers from another.
Line length? Not a problem. Forcing the hard-of-sight dev to indent however _I_ see fit? I wouldn't dream of doing that.
I’d love to set up terminal tabstop size, textview tabstop size, github tabstop size, IM tabstop size, HN tabstop size, git gui plugin tabstop size, issue tracker tabstop size, tsv file format tabstop size if I used tabs. It makes you so productive.
Seriously, this takes yak shaving to a whole new level.
To be honest, that's why I love auto formatting cause I never need to think about that stuff, I can just write code.
The real problem is that using spaces for indentation is an accessibility issue.
The solution is to use tabs for indentation, and spaces for alignment.
Not this again
https://github.com/prettier/prettier/issues/7475#issuecommen...
> Blind programmers have no problems with it.
We're struggling with the wrong problem if we aren't asking why the editor can't treat blocks as entities that are displayed however we want.
> why the editor can't treat blocks as entities
If you have something like:
var (
x = foo
other = bar
)
coolFun(arg1,
arg2)
->coolFun(arg1,
-> arg2)
--->coolFun(arg1,
---> arg2)
------->coolFun(arg1,
-------> arg2)
The problem is when you start doing stuff like:
if (one) {
------>if (two)
bar();
------>else
xxx();
}
That's what people mean with "don't mix tabs and spaces", not "if you use tabs then the space shall never appear in the file under any condition".
This is clearly false. You said this after giving a perfect example of how it's done with tabs.
-------->coolFun(arg1,
-------->------->arg2)
https://superuser.com/questions/710019/why-there-are-11-tabs...
> This is clearly false. You said this after giving a perfect example of how it's done with tabs.
I believe the post you're replying to meant "used more tabs". That is, if you used any tabs beyond the code indentation, they would get altered when you change the indentation size and ruin the alignment.
When I made my original comment I thought what I was replying to was an example of "tabs to indent and spaces to align" immediately followed by a statement that the only way to use tabs is to both indent and align.
Aligning lines in the same block
____var a; // indented with a tab
____var b; // indented with a tab
____var a, // indented with a tab
____----b, // indented with a tab, then aligned using spaces
Another alternative is elastic tabs, where tabs are used for both of those, but are converted to an indentation/alignment number of characters semantically. I like the idea, but I've yet to see a good implementation.
Personally I'm a fan of all spaces, but that's mostly because every company I've worked at has used that.
int foobar(int a,
___________int b) // should only ever have spaces (using _ here because HTML)
But good luck finding an editor that won't insert a tab when you use the tab key here (willing to be wrong).
The other issue I have is that diffs break alignment between undented code and anything with tabs because the tabs "eat" the leading space, but unindented lines are offset by one.
I've had some editors that made tab-space conversion an option, but it was never mandatory.
I've not done lots of development with other editors, but Kate didn't do it and the few times I used Visual Studio, it also had similar behaviors (I'm assuming VSCode inherited that stuff).
https://lore.kernel.org/keyrings/20221109025019.1855-2-linux...
If HN mangles the link, it is the addition of the `key_create` function in this thread: https://lore.kernel.org/keyrings/20221109025019.1855-2-linux...
It's the second step that drives me nuts. Why can't/doesn't alignment happen at first step? The inconsistencies of alignment using true tabs, in a monospace plain text environment, grosses me out and decrements my faith in the underlying systems. I appreciate editors w/ settings like `insert spaces when pressing tab` and `the number of spaces a tab is equal to`.
The problem of leading spaces not changing their size can be solved through programming.
Those programmers who have such a problem and need leading space to be rubbery, if those programmers are worthy, will solve that problem instead of complaining that everyone should adapt to them.
The use of tabs is detrimental to code bases. Whenever tabs creep in, invariably people use different tab settings and make a dog's breakfast out of the code.
Code exhibits indented sub-structures that are internally indented, but not themselves not aligned to a tab stop, but aligned with something. One kind of example is something like:
function_name_of_random_length(lambda (a, b) {
if (a < b) {
indented();
}
},
arg2);So I'm not convinced the problem you're describing should ever happen.
(if you accidentally use a tab in a file that otherwise uses spaces, you get a runtime exception, or vise versa)
So when your team is compiling locally they don’t type check? It only runs in the IDE and during tests?
But I tried my best to make the build have fast paths to minimize the development loop as much as possible.
Even on an absolutely gigantic codebase using tabs or spaces will make almost no difference to build or type-checking times. Building an AST is much more overhead than white space considerations and once it’s an AST tabs or spaces are not included in the running of the code.
> [...]
> The TypeScript package now targets ES2018. Prior to 5.0, our package targeted ES5 syntax and the ES2015 library, however, esbuild has a hard minimum syntax target of ES2015 (aka ES6). ES2018 was chosen as a balance between compatibility with older environments and access to more modern syntax and library features
I'd be curious as to what percentage of the improvement comes from modules vs comes from a different target.
From my superficial knowledge of compilers, "modularization" itself should not make code faster, if anything slower. There'll always be some overhead of loading modules and communicating between them, not?
I presume, from my own experience when building software (not compilers), that modules allow for a much easier to reason about, much better isolated (cohesion, loose coupling). And therefore for much easier improvements inside the module. I would presume that, here too, modules allowed them to improve the inner workings much better, allowing for the performance increase. Or am I completely misunderstanding this feature?
Firstly, the old codebase is TS namespaces, which compile down to IIFEs that push properties onto objects. Each file that declares that namespace is its own IIFE, and so every access to other files incurs the overhead of a property access.
With modules, tooling like esbuild, rollup, can now actually see those dependencies (now they are standard ES module imports) and optimize access to them. In this PR's case, the main boost comes from scope hoisting.
For example, in one file, we may declare the helper `isIdentifier`. In namespaces, we would write `isIdentifier` in another file, but this would at emit time turn into `ts.isIdentifier`, which is slower. Now, we import that helper, and then esbuild (or rollup) can see that exact symbol. All of the helpers get pulled to the top of the output bundle, and calls to those helpers are direct.
That's why modules gives us a boost. There's also more (modules means we can use tooling to tree shake the output, and smaller bundles are faster to load), but the hoisting is the big thing.
Most Typescript projects today wouldn't use TS namespaces if you paid them too. It's a backwards "module format" that the modern web and modern Node (and Deno) is trying to leave behind. Several issues and PRs have been filed on Typescript to drop namespaces as a first-class syntax altogether because it unnecessarily confuses newcomers and shouldn't be used in new code in 2022, but there are some major pre-1.0 Typescript projects that still need them for legacy reasons. Typescript itself bootstrapped itself with itself and was one of those large projects with such a legacy dependency, hah. (From the PR you can see precisely how much tech debt that this has left in Typescript's own codebase!)
So, long story short: esbuild doing a bunch of work to support jQuery-era IIFE patterns is maybe not the best use of esbuild developers' time in 2022.
You are correct that initializing many modules is usually slower than initializing one module [1]. However, bundling puts all modules into one file, so this PR doesn't actually change anything here. Both before and after this PR, the TypeScript compiler will be published as a single file.
At run-time, switching to ES modules from another JavaScript module system can be a significant performance improvement because it removes the overhead of communicating between them. Other module systems (e.g. TypeScript namespaces, CommonJS modules) use dynamic property accesses to reference identifiers in other modules while ES modules use static binding to reference the identifiers in other modules directly. Dynamic property access can be a big performance penalty in a large code base. Here's an example of the performance improvement that switching to ES modules alone can bring: https://github.com/microsoft/TypeScript/issues/39247.
[1] This is almost always true. A random exception to this is that some buggy compilers have O(n^2) behavior with respect to the number of certain kinds of symbols in a scope, so having too many of those symbols in a single scope can get really slow (and thus splitting your code into separate modules may actually improve initialization time). This issue is most severe in old versions of JavaScriptCore: https://github.com/evanw/esbuild/issues/478. When bundling, esbuild deliberately modifies the code to avoid the JavaScript features that cause this behavior.
I think this is a misunderstanding of what actually happened.
TypeScript has a thing called “namespaces” and a thing called “modules”. Both provide modularization. The TS repo is not being modularized, instead, the namespaces are getting converted to modules.
Namespaces are an old-school approach to writing a module in JavaScript. You pack all of your exports into a JS object, and then access the object from somewhere else. This works, but JS is dynamic, and the runtime has no way to guarantee that you won’t mess with this object (replace functions or whatnot).
Modules don’t have this object. You just call the function, instantiate the class, or do whatever else with the names you imported. They are resolved statically, so certain optimizations become more “obvious”, like inlining.
I’m curious, how many people are using TSC only for type-checking, and a different system (eg esbuild or ts-node) to actually compile/bundle/execute their code?
Looks like my suspicion was correct; not even tsc uses tsc!
This seems to me like a great "win" for Typescript that so many tools just natively handle TS type stripping and that so much Typescript today only needs type stripping and doesn't need other parts of TS emit processes (or tslib).
I find it interesting that one of the reasons given for the reduction in package size is due to such a simple indentation change from 4 spaces to 2 spaces.
Not interesting that 2 bytes are less than 4 bytes, rather, TypeScript is a large project and it would be interesting to know how much size was saved from this one specific change? Seems like a trivial change, so why not do it sooner? And assuming readability isn't required in the bundle output why not bundle with no indentation at all and put everything on a single line, would this not be even smaller again?
Re: indentation: Literally, no one thought of it, as far as anyone can tell. Linus's law appears to have its limits.
I think it's probably correct to laugh this off though. Why would you care about the non-minified/gzipped size this much?
utils/foo.ts
you have to import it as
import Foo from "utils/foo.js"
Even though there is no .js file on disk, and you might be running ts-node or whatever that doesn't build a .js file.
Importing a file that "doesn't exist" is so counterintuitive.
In addition all code breaks because you have to change all your imports, and /index.ts or /index.js won't work either.
1) enforces no extension, e.g. “utils/foo”, or
2) allows TS extensions, e.g. “utils/foo.ts”
I have never imported a TS file using a JS extension. Maybe your woes could be fixed with a configuration change?
That's because typescript developers are dead set that they don't want to transpile the imports, they just want to copy paste them into the resulting file when running tsc.
[1] https://github.com/microsoft/TypeScript/issues/50457
The Whole ESM saga is clusterfuck, not much better than python 2 -> 3 migration. Large node.js codebases have no viable path to migrate, and most tools still cannot support ESM properly[3]. Stuff is already breaking because prolific library authors are switching to ESM.
As someone that maintain large part of TS/JS tooling in my day job, I absolutely despise decisions made by node.js module team. My side projects are now in Elixir and zig because these communities care about DX.
[1] https://nodejs.org/api/esm.html#differences-between-es-modules-and-commonjs
[2] https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-7.html
[3] https://github.com/facebook/jest/issues/9430They'll cite some nebulous technical reasons of why it has to be this way, but if you offer a PR that actually solves the issue that the community complains about, they'll reject it.
In this case they decided that tsc won't transpile imports. They just did and it's "policy" and it can't be changed. It doesn't matter if it is awful for compatibility, developer experience, etc. It's just the policy. Issues will be closed. And no, even an optional flag to transpile imports is off the table, even if you write the PR for it.
There are many many issues opened related to this in github, but to give an example
This explanation in the comments makes sense to me:
Transpilers can add the ability to add extensions at compile time, so a specifier like './file' can be rewritten to './file.js' during compilation along with whatever else is getting converted by the transpiler.
It seems sensible for Node to expect fully-qualified imports, just like a browser would. And (to me) it seems sensible that in a language like TypeScript you should be able to import “foo.ts” and it have it transpiled to the correct filename.
Now, that does not work in TS because they adamantly refuse to modify any of the emitted JavaScript code at all, with no clear explanation except that it’s long-standing policy. Instead they expect you to import “foo.js” in TypeScript, even though that file doesn’t exist until after compilation. That’s a problem, and it seems like it’s caused by the TS team, not Node.
> Now, that does not work in TS because they adamantly refuse to modify any of the emitted JavaScript code at all, with no clear explanation except that it’s long-standing policy. Instead they expect you to import “foo.js” in TypeScript, even though that file doesn’t exist until after compilation. That’s a problem, and it seems like it’s caused by the TS team, not Node.
I think they should provide a better explainer. But node.js resolution algorithms is already incredibly complicated, and adding path rewriting to typescript is not going to make it better. There are things like dynamic import and third part libraries. Typescript would need to either analyze whole of project node_modules or bundle custom runtime resolver like webpack breaking compact with deno and friends.
Imagine situation:
import lib from 'somelib/subpath'
> Hmm, what is it that Node is doing that’s so bad? I don’t understand why that issue is a big problem.
My conclusion is that successful projects without BDFL are prone to corporate takeovers. You have people that working in corporations without writing code and want to make political career as "core" team member of project.
Node requiring the .js is more understandable, as that actually affects runtime performance: if the name isn’t fully qualified in source then node needs to stat() more paths during resolution.
> What if typescript is running in deno/bum or wasm?
Every TS project already needs a tsconfig.json to specify what permutation of module system configurations it is using.
Performance is affected only during startup by maybe few milliseconds. This is a major breaking change to module resolution made by node.js. Why TS should paper over change that was made by node.js.
> TS can already perform complicated refactorings, such as renaming all imports in a project when you rename a file in vscode. So they definitely have all the information they need already.
Some things are supported by tsserver not typescript compiler. Fixing this in TS is only addressing the problem partially and is shifting the problem into tools developers.
Typescript decided that they don't always know what output file extension you may need because Node made that logic way too complex and they don't want to just reimplement their own buggy version of Node's loader mechanics but "backwards" in a terrible "guess the file extension" game, so they went with the easiest option which was "user now has to tell us the file extension".
Even if Typescript didn't have a policy to reduce the number of modifications it emits, it's still Node's fault that the file extensions now have three options with an extremely complex dance between them and getting a "guess the file extension" game right would be an extended PITA.
If you’re just using TSC to typecheck and not emitting code (which is what most people actually do in practice), it’s even easier -- just let me import “foo.ts” if that’s the name of a file that exists. The popular bundlers can all handle that just fine.
Typescript may have a complete view of a single project, in which case yes, it should know what file type it is emitting in that project, but then it has to track "in project" imports differently from "out of project" imports and needs two different behaviors for those.
All of that gets further complicated by incremental builds and multi-project references and multi-project references with incremental builds.
Which isn't to say that it isn't technically solvable, and maybe "two behaviors" is an alright developer experience even if it would confuse so many new users, it's just that there are a lot of obvious complications in the face of it.
It's also not like they haven't been trying to work on it. Other comments in this thread have pointed to at least one Typescript issue on it. At one point Previews supported a version of this but rather than using the file-type of the current package's emit it relied on the new paired TS file types: .ts => .js, .mts => .mjs, .cts => .cjs. If you imported a ".ts" it always assumed you were importing ".js" and if you imported a ".mts" it always assumed you were importing a ".mjs". There were a lot of complications even with that simple "one experience", but even that experience was terrible, fell down in complications with Node's loader and various bundlers, and had too many bugs. So it was pulled from Previews.
When I look at the multiple(!) issues on TS GitHub asking “please, can we just import .ts files with a .ts extension? That would make life a lot easier”, the comments from the developers pushing back on it aren’t about Node integration issues, they’re about the unshakable principle that TS must never rewrite syntactically valid JavaScript at all.
Make it work within a single project, at least, and leave external projects for later.
Edit to add:
There were a lot of complications even with that simple "one experience", but even that experience was terrible, fell down in complications with Node's loader and various bundlers, and had too many bugs. So it was pulled from Previews.
Do you have a link handy for that discussion? I’d be interested to read it.
Which is starting to be a very useful principle of Typescript. Typescript knows that today it is not your bundler and tries to leave almost all rewriting to your bundler. That leaves bundlers able to strip types without even needing a direct dependency on Typescript. This is why tools like swc and esbuild written entirely in other languages now type strip as well.
This is also why the Typescript team has been a proponent for a proposal to add type stripping (or something like it) to the entire web platform. (There's a Stage 1 proposal in TC-39's process.)
You may not find that useful, but there's a growing ecosystem around "Typescript is just for types, not also for deeper transpilation". It is not just TS developer being "high and mighty" in the face of things you think they could make the developer experience easier on.
If TypeScript isn’t the bundler, it shouldn’t complain (as it currently does) when you import a “.ts” file. It shouldn’t care at all!
You can likely change it with a config, but do note that importing using .js will be the new standard way of doing things and by changing it through configuration you’re chosing to not follow the new standard.
It’s a complete mess IMO. Every project uses a different way to handle modules and there’s a lot of rough edges.
See https://github.com/microsoft/TypeScript/issues/37582 which is referenced in the 4.9 Iteration Plan as "Support .ts as a Module Specifier for Bundler/Loader Scenarios": https://github.com/microsoft/TypeScript/issues/50457
See https://www.typescriptlang.org/docs/handbook/esm-node.html for details about how import paths work in CommonJS vs ESM. In both cases the import path you write in your source code is the same import path that is used in the emitted JavaScript. What's different is that NodeJS's ESM implementation doesn't allow extensionless import paths (but its CommonJS implementation does).
> | edit [–] | on: PR that converts the TypeScript repo from namespac...
Potentially, an approach like this might be applicable to other changes; I have a commit in my stack which moves the old build system config to the new build system config's path (even though it's wrong), as git does a much better job understanding where the code is going if you help it.
Thank you for the kind words!
I reported typescript install size issue back in 2018 and changing to modules seemed to have the biggest impact here!
https://github.com/microsoft/TypeScript/issues/23339
For anyone curious, TS 1.0 was 7MB and today it’s 65MB.
https://packagephobia.com/result?p=typescript%401.0.1%2Ctype...
Really excited to see this number move in the downward direction for a change :)
I have a gameplan to drop this by another 7 MB (by turning our executables into ESM), probably for 5.0 as well if we decide that Node versions older than 12 are worth dropping.
There is a lot of interest in making typescript fast but all of them want to do a rewrite. Swapping the slow parts seems a lot more viable
Yes, multithreading is awesome and really helpful but it's the cherry on top, not the whole thing. If the same amount of effort was put into optimizing the TSC codebase as it is being spent to rewrite it in Rust, I have no doubt that it can become faster. Perhaps it'll require some big changes but it won't create compatibility concerns and it won't be a cat-and-mouse race between the Rust version and the TS version.
I don't think "Write it in Rust" is always the solution to fast programs. Rust itself can be pretty damn slow if you don't keep performance in mind. That is why you have to optimize and profile and optimize over and over again. Can't the same be done for TSC?
I think the biggest reason devs don't do this is because no one likes profiling and optimizing since it is a slow and boring task. Rewriting is so exciting! It's the thing you do when you are tired of maintaining the old codebase. So just ditch it and rewrite it in Rust.
I have nothing against Rust, mind you. I love what it has done but I don't think rewriting everything is either feasible or even the solution. And waiting for that to happen for every slow tool out there is utter foolishness.
> Because of this smaller scope, Sucrase can get away with an architecture that is much more performant but less extensible and maintainable. Sucrase's parser is forked from Babel's parser (so Sucrase is indebted to Babel and wouldn't be possible without it) and trims it down to a focused subset of what Babel solves. If it fits your use case, hopefully Sucrase can speed up your development experience!
The aspect of the language you're using, if optimized, is virtually always optimized for the most common use-case. If your use-case isn't the most common use-case, you must account for this.
Arguably, the real problem is that GCC et al are enablers for poorly written programs, because no matter how mediocre a program you compile with them, they tend to do a good job making those programs feel like they're performance-tuned. Today's trendier technology stacks don't let you get away with the same thing nearly as much—squirting hundreds or thousands of mediocre transitive dependencies (that are probably simultaneously over- and under-engineered) through V8 is something that works well only up to a point, and then it eventually catches up with you.
Besides, there's no such thing as a fast or slow language, only fast and slow language implementations.
As a bonus, the code is now statically typed
If JS is only half the speed of a compiled language like Rust, that shows remarkably optimized performance.
Things don't need to be "exceptionally" fast to be in the area where programming language doesn't really matter.
> Twice the performance on a server could let you handle twice as many concurrent sessions (and possible run half as many servers!)
Which might matter, or it might not. Very situational.
> People regularly fight tooth and nail to squeeze 10% performance boosts on critical tasks, doubling it would be incredible
That kind of task is a small fraction of tasks. And often you're best off using a library, which can often make its own language choices independent of yours.
The tradeoff is that Rust is lower-level, so it is harder to write. If performance were the only point of comparison for a language, then we'd all be using assembly. We choose to trade performance for productivity when we're able to.
https://github.com/alangpierce/sucrase/blob/153fa5bf7603b9a5...
But freaking SIGH I don't want to. I prefer coding in environments that don't require unrolling loops by hand.
https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with...
https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to...
https://fitzgeraldnick.com/2018/02/26/speed-without-wizardry...
As I am getting older, I do not want to spend my weekend learning about new features in next.js v13[1]or rewriting tests from enzyme to RTL[2]. I want to use programming language that value its users time and focus on developer experience.
[1] https://www.youtube.com/watch?v=_w0Ikk4JY7U [2] https://dev.to/wojtekmaj/enzyme-is-dead-now-what-ekl
See in my fork, swc is winning :P https://github.com/chyzwar/sucrase
Once swc-cli is re-written in rust with better IO results could be even more impressive.
Could this not have been done incrementally?
I have tested the merge conflict problem, and thanks to the way the PR is constructed (in steps), git actually does a good job figuring things out.
Did you consider _not_ re-indenting the entire code base and rely on the auto formatters of contributing people? Did you consider re-formatting parts of the code step-by-step, beginning with code that's not frequently changed?
Didn't know about the feature that ignores commits in git-blame, thank you for that.
I didn't consider doing it step by step, no, but I'm not sure how I would really achieve that effectively. The reality is that the bulk of PRs are submitted by the team, and it's straightforward to get everyone to get their code in before this change, pause merges, rebase, and then continue as normal. I'd rather go for the "rip the band-aid off" method.
That's what I was worried about, but I guess you can't have merge conflicts if you freeze the code.
Suppose you couldn't freeze the code, then what would you have done?