Been using tsgo preview to build and typecheck our project for a while. It's pretty great. Managed to finally do a full typecheck on pre-commmit(via lefthook) and it's fast enough to not even bother me when committing work.
it's nice to be able to catch a small compiler error immediately before you even push rather than need to rerun the entire CI pipeline after context switching to something else
So you've decided that pushing your code to other people is the appropriate way to check if it works?
It sounds like you understand the utility of ensuring that the code passes type checking before it ever gets pushed to remote and run through a CI pipeline.
Not a big fan of commit hooks myself, but the utility is to have the check an automatic process instead of having to run it manually before pushing. Now it doesn't really matter if you push and it breaks CI, but the turnaround time is higher
This thread is an interesting read. Do people really just throw things up to CI/CD without having simple utilities watching changes and running unit tests, linting etc etc and then the various checks within your IDE/editor running in real time?
Pre-commit hooks do have a place, but there’s a guy getting downvoted to oblivion basically questioning why people don’t just develop in a sane matter.
That's already the job of the language server inside your code editor. T7s is literally going to enable real-time, project-wide error listings as you code. Until now, it could only check the files you have open.
It's problematic. Let's use that word. CI/CD is a productivity tax because it does take time to run, and so you have to decide how many times you want to pay that tax. An "awake" developer is going to test their code to make sure it actually works before pushing up to CI/CD. That means you're asking them to pay the tax 3 times -- once because they're competent, twice because some of their colleagues migtht be asleep behind the wheel when they push up CRs, and thrice when your actual CI/CD pipeline must run. Take a CI/CD run that takes 5 minutes to run, and suddenly that's already 15 minutes minimum. For a highly productive developer who is capable of publishing, let's say, 10 pull requests per day, that's 150 minutes of their day.
Once ago showing that you have no idea what cargo cult programming is.
The down votes clearly show that there are plenty of folks who either do find value in precommit hooks, or who are wondering why you think a precommit hook is the same thing as a whole ci/cd pipeline build.
What is it that you actually believe that a cargo cult is? It's not just about chocolate bars, I'll have you know.
But okay I'll byte. It's not just a cargo cult. It's a mass delusion built around impostor syndrome. The benefit that you feel you're getting from pre-commit hooks is the fear you have of pushing up a commit because you're afraid that everyone will find out that you can't code.
Cargo cult programming is more about someone not understanding something so including pointless comments, using design patterns that make no sense, etc. Precommit hooks live in a directory you'll never see if you don't want to change them or interact with them. So they don't affect the codebase in any meaningful way that could possibly be construed as cargo cult programming.
At least once a week a push code and send my ticket to code review. Then it comes back to me "failed the formatting check". Wasting the reviewers time and forcing me to context switch to get back to the ticket and fix the formatting.
If I set up a precommit hook that auto formatted any files with changes in them it would take maybe a second to run on each commit and save me and the other dev that wasted time.
I break the build more than anyone on our entire team. I'm not afraid of pushing bad code. I'm a fan of preventing bad code in automated ways. Precommit hooks can do that. Which reminds me that I keep meaning to set one up to avoid the problem that I mentioned.
Okay look you're being very honest here about some issues you're trying to overcome so I'm not going to pick on that, I never punish honesty. But your definition of cargo culting is fascinating, and wrong, so let's talk about that.
You should read Richard Feynman's 1974 commencement speech where he introduced the concept to the scientific community. Because where you've got it wrong is in thinking that cargo cult programming is an individual activity. The key word is cult, it means there are many participants. Feynman was condemning entire scientific fields of research, in particular education and psychology. He was condemning best practices that appear scientific on the outside, and are adhered to by thousands of people, but that are meaningless and don't actually prove any of the things that the researchers collectively believe that they prove.
This is why cargo cult programming is about group delusions -- beliefs in a process that everyone follows, but that doesn't actually achieve what they think it does. It's not about one guy who writes too many comments, or makes a bad decision with their software architecture.
Right, that's what I'm trying to explain to you, but you just have to read past the introductory paragraph.
slavishly following a software development process without understanding the reasoning behind it
This would be pre-commit hooks in this case. Let's take a moment to address your probable concern about code comments.
Unnecessary comments are a cargo cult when they are a mandatory part of a baseless development process. Like when management forces the entire company to write code comments because he believes that well-commented code is more maintainable.
It's not, simply, when an individual programmer writes comments that he thinks are useful to himself, but that other people don't find useful.
At no point during any of that did you make a valid point for how pre commit hooks meet your own definition of cargo cult programming.
slavishly following a software development process without understanding the reasoning behind it
Plenty of commenters, myself included, have explained why precommit hooks are useful and their reasons for using them.
You are unable or unwilling to understand that, and insist that everyone who finds value in precommit hooks is trying to shove their entire ci/cd build into them and wasting five minutes every time they commit.
Point of order - I never called it cargo cult programming, only you did. I called it cargo culting. If your entire objection is that executing a hook is not a literal act of typing code, that's just on you.
The proof is in the pudding. This very thread, with the many people who fall into severe levels of cognitive dissonance after I pointed out the obvious -- that the practice of linting in pre-commit hooks is superfluous, redundant, and a drain on their own productivity. They make grandiose claims of the amazing things that it does for them -- saves them millions of dollars on CI/CD servers, avoids the criminal offense of failing a CI run, "automates" the hardest part of their job (checking if their code compiles). It's all been a whirlwind of nonsense.
"Competent" people are capable of occasionally forgetting to run type checking/linting/formatting checks prior to committing their code.
The productivity cost of getting an email 5 minutes after you push your code and having to context switch back, read the error message, swap branches, fix the issue, test, and push again is way lower than the cost of hitting that same error when you are about to commit the code when you still have the full context so you can resolve the issue faster.
Also the entire premise of this suggestion was that the new typescript compiler is fast enough that this is feasible. I don't think anyone is suggesting forcing developers to wait 15 minutes before they can git commit, but 1-2 seconds is a perfectly reasonable cost to ensure that any committed code is considered correct from the perspective of tsc.
You're trying to sell me on the idea that I should pay the 5 minute cost 100% of the time because if I don't, then 1% of the time I might lose 5 minutes. Your math doesn't math.
If you thought five minutes was that important you wouldn't be wasting everyones time with your dumbass arguments against automating a manual process that can be forgotten.
Weak. You deflected so hard, it's obvious you realized that your math doesn't math.
I don't care about what you do with your time -- it's obviously not important to you. I'm also not here to hold your hand and fly a little airplane into your mouth to get you to realize that you're wasting your own time with a cargo cult developer process.
you're getting so hung up on 5 minutes this 5 minutes that. put all your CHEAP checks in your pre commit hook (formatting, linting, type checking, etc). now you don't need to pollute your commits with "chore: fmt" or whatever. you definitely don't need to run your ENTIRE pipeline locally before pushing.
also, nobody is FORCING you to use the pre commit hooks. if you're john 10x developer himself, by all means commit tax evasion and delete the hooks or use --no-verify on your commit. the premise of everybody arguing against you is that you can frontload cheap checks and not worry about them when you're getting your review.
Who said I'm hung up on it? You're using sleight of hand by claiming that a type check is fast and cheap? First of all we wouldn't even be here if it was fast and cheap. Second of all, the type check comes "for free" when you run your unit tests.
So what are you confessing to here? That you don't write tests, and you don't run tests, before you push up commits? That your unit tests are rarer than hen's teeth? That the codebases you work on professionally are little more than hello world demos?
Explain yourself. What are you doing wrong that makes your pre-commit checks something other than redundant, and simultaneously so incredibly fast that you can't even notice them running but yet so critical that it would be a literal calamity if the remote CI/CD server -- which is going to run all of the same crap anyway -- can't possibly deal with immense load you're putting it under.
It doesn't take 5 minutes to run it locally because you already have the dev environment setup, so you don't have to pay the cost of setting up the whole project from scratch like the CI pipeline has.
It takes 400ms to typecheck our project with the tsgo preview checker and around 3 minutes for the CI to set it all up and run the same check.
The number of times I've seen a sub-5-minute CI job in my professional life is equal to the number of times I've set it up myself. People literally run the full CI/CD in a pre-commit hook because they have a 45 minute build and some fucked up CI pipeline that might have 10 workers across 100 engineers.
Your perspective here is problematic. Let's use that word.
You don't need to wait for a CI run to complete to continue working. If the pre-commit hook takes on the order of a couple of seconds, it is essentially free relative to the network traffic.
It's just a pointless block on your local repo, preventing you from changing branches and writing the next set of code.
The point of making CI/CD fast isn't to multiply the number of times that you have to run it, as that defeats the whole point of lowering the productivity tax.
Right so running operations locally to make sure it's clean before moving to a CI/CD pipeline reduces cycles and ensures it remains fast and error free.
Things like local linting on files changed, type checking, or even in extreme cases testing on either pre-commit or pre-push ensures that errors doing get leaked into a pull request to annoy you since it does for whatever reason
It doesn't save money on CI/CD. All it does is save face for the one guy who doesn't bother to test his code before pushing it up for review. It hides the signal from the rest of the coworkers that oh, here comes an incompetent/distracted colleague who didn't test their own code, this code review is going to be a doozie.
If the only thing ci/cd did was run my unit tests and literally nothing else, I could consider agreeing with you. There are a bunch of other things that are unrelated to the code working that can cause ci/cd to fail, and I'd rather have my machine spit those out immediately, instead of waiting for an email from circleci that says I forgot to delete an import that I'm not using anymore.
If you're talking about the emails that say that you've leaked your secrets to the open internet, I'm inclined to agree. It's best not to get those kinds of emails to begin with.
But you're not actually talking about that. You're not saying that things where the pre-commit hook is the last possible place to perform a check before the damage is permanent and severe. You're talking about the things where the CI/CD system on the build server is the last line. You're talking about getting an email which triggers some sort of OCD response from you, but doesn't actually mean anything.
Because it takes <500ms to do so, instead of running entire Github Workflow(whatever else you're using), that pulls (maybe cached) npm packages, docker images, builds everything and then spams your slack(or you have to check manually).
No pain, no gain, as they say. If the only thing you're running before you push up a commit is a 500ms linter then you're going to end up with far more build failures far more often than you thought. Unless your build process is made out of hopes and dreams.
Nobody said you shouldn't try compiling your code before you push it to a remote build server. What they said is that it's stupid to do that one thing in a pre-commit hook, when there are in fact a bunch of other things including that that you should be running, together, throughout the entire process of writing your code. You know, like unit tests. It's stupid to do something that adds no value, even if it only costs you 500ms. It's still 500ms of bullshit.
I'm not going to continue this because you clearly don't want a discussion, you want to show to everyone why you're right even though you know absolutely nothing about me, our project, needs or experiences. You'll grow out of that phase soon enough, good luck.
There's not much for me to grow out of considering I'm already a principal engineer and my job is to deal with hundreds of juniors who repeatedly come up to me with the same bad ideas that I've heard a thousand times before, but this time they think they're special.
Over the past year, we have been porting the existing TypeScript codebase from TypeScript (as a bootstrapped codebase that compiles to JavaScript) over to Go. With a combination of native code speed and shared memory parallelism, TypeScript 7.0 is often about 10 times faster than TypeScript 6.0.
If I understand correctly, this is specifically about the transpiling process? Was that an issue before?
At first i thought they were saying code written in ts7 would be so much faster, which doesn't make much sense
On larger codebases, or just codebases that trigger slow paths in the TS type checker, it could get very slow. This is used in your IDE too via the language server, so performance improvements make a big difference. On our codebase, go to definition often took 20+ seconds and code completion was barely functional. With tsgo, it's smooth (albeit at the cost of using ~10GB of RAM).
Same, my former job used autogenerated types for a big Graphql schema which resulted in huge, extremely complex types, and the burden in the compiler and our editors was HUGE
With tsgo, it's smooth (albeit at the cost of using ~10GB of RAM)
oh the insane RAM usage is still a thing? great. Maybe in another 10 years they'll do another rewrite to make it actually performant... webdev really cannot beat the allegations.
You don't need it for transpiring, you need it for type checking. There are plenty of very fast transpilers that simply strip the type annotations away and turn the code into plain javascript.
TS is basically a linter. Zero runtime overhead (for the most part). And there's a proposal to add optional type annotations to JavaScript itself so browsers can run the code (not type check the code) without having to strip the types first.
Both acknowledged as a mistake, and hence why nowadays they focus on being a linter and nothing else, other than maybe getting some JS features in advance with polyfills like Babel.
You also don't write the code "in" ts7, you compile it with ts7
Given that ts7 also identifies a typescript standard and constructs that are valid in ts7 would error in ts3 it is correct to say "we're writing in ts7" just like you could say it about C++17
Kind of, the team learnt not to be another Dart or CoffeeScript, hence why except for enums and namespaces, Typescript is basically a linter.
The only "language" changes are always related to improvements on the type system, and ways to generate JavaScript code that are less painful with all the tricks that one can pull in a dynamic language like JavaScript.
And just like Babel, provide features in advance than can be polyfilled (not all can, if they require JS runtime changes), but are already mid way on the JS standard process.
I’m kind of surprised they were allowed to use Go. When I was at MS there was a big bias against Go because it is Google and Google is known for killing things off.
Even more surprising is that Microsoft has gone back to Java as well, they have their own OpenJDK distribution and were the contributors for Windows ARM support for the OpenJDK.
Since Satya took over, Microsoft became a polyglot shop, go to https://devblogs.microsoft.com and check the languages drop down.
The tragic part about using Go instead of Native AOT, given the Typescript architects background, is that kids that want to contribute to Typescript will learn Go, while .NET team complains about lack of adoption on macOS/Linux.
Go is stable enough and with huge userbase that goog nixing it won't matter at this point. Other huge companies from FANG using it could maintain a fork alive. gcc also maintains an independent compiler gccgo, though it isn't used extensively by companies iirc.
Always interesting to see how TypeScript evolves without breaking everything. Curious if 7.0 brings more performance improvements or if it’s mostly type system tweaks this time.
the Go rewrite compile speedup is the headline but the real win for large monorepos is incremental checks that actually finish. Waiting 45s for tsc --noEmit to rescan after a one-line change was the worst part of 6.x.
Atraac@reddit
Been using tsgo preview to build and typecheck our project for a while. It's pretty great. Managed to finally do a full typecheck on pre-commmit(via lefthook) and it's fast enough to not even bother me when committing work.
CherryLongjump1989@reddit
Running the compiler in a pre-commit hook is redundant. You still have to run it on your CI/CD server.
lifeliverDTN@reddit
it's nice to be able to catch a small compiler error immediately before you even push rather than need to rerun the entire CI pipeline after context switching to something else
CherryLongjump1989@reddit
So you've decided that pushing your code to other people is the proper time to check if it compiles?
lifeliverDTN@reddit
It sounds like you understand the utility of ensuring that the code passes type checking before it ever gets pushed to remote and run through a CI pipeline.
CherryLongjump1989@reddit
There is no utility in what you're describing. The CI pipeline isn't getting its feelings hurt. What are you even talking about?
kallekro@reddit
Not a big fan of commit hooks myself, but the utility is to have the check an automatic process instead of having to run it manually before pushing. Now it doesn't really matter if you push and it breaks CI, but the turnaround time is higher
fel@reddit
This thread is an interesting read. Do people really just throw things up to CI/CD without having simple utilities watching changes and running unit tests, linting etc etc and then the various checks within your IDE/editor running in real time?
Pre-commit hooks do have a place, but there’s a guy getting downvoted to oblivion basically questioning why people don’t just develop in a sane matter.
CherryLongjump1989@reddit
That's already the job of the language server inside your code editor. T7s is literally going to enable real-time, project-wide error listings as you code. Until now, it could only check the files you have open.
azsqueeze@reddit
What's wrong with pushing code to a feature branch for a pull request?
CherryLongjump1989@reddit
Nothing at all. That's where you have a CI/CD tool that will compile your code and run the tests and then report the issues back to you.
The problem I have is with this concept of trying to run your CI/CD tools as part of a pre-commit hook on your local machine.
battlesqui_d@reddit
...they aren't mutually exclusive...?
CherryLongjump1989@reddit
It's problematic. Let's use that word. CI/CD is a productivity tax because it does take time to run, and so you have to decide how many times you want to pay that tax. An "awake" developer is going to test their code to make sure it actually works before pushing up to CI/CD. That means you're asking them to pay the tax 3 times -- once because they're competent, twice because some of their colleagues migtht be asleep behind the wheel when they push up CRs, and thrice when your actual CI/CD pipeline must run. Take a CI/CD run that takes 5 minutes to run, and suddenly that's already 15 minutes minimum. For a highly productive developer who is capable of publishing, let's say, 10 pull requests per day, that's 150 minutes of their day.
belavv@reddit
You seem awful confused. Devs often use pre commit hooks to verify specific things are done/valid on a file before pushing their code.
That precommit hook can run on only the changed files in some cases. You aren't running the entire ci/cd pipeline in a precommit hook.
CherryLongjump1989@reddit
I've disabled enough pre-commit hooks to know what developers use them for and why it's almost always a bunch of aspirational bullshit.
belavv@reddit
Well you can leave them disabled and devs that find them useful can leave them enabled. Crazy how that works!
CherryLongjump1989@reddit
Cargo cults stay real even if you don't join them.
belavv@reddit
You should probably go read up on what cargo cult programming is and then come back to explain how that applies to setting up a pre commit hook.
CherryLongjump1989@reddit
Re-read this whole thread and you'll find out.
belavv@reddit
Sure bud. I'll go back and count up all your down votes while I'm at it.
CherryLongjump1989@reddit
Downvoting someone who points out that your practices don't work doesn't exactly prove that you're not in a cargo cult.
belavv@reddit
Once ago showing that you have no idea what cargo cult programming is.
The down votes clearly show that there are plenty of folks who either do find value in precommit hooks, or who are wondering why you think a precommit hook is the same thing as a whole ci/cd pipeline build.
CherryLongjump1989@reddit
What is it that you actually believe that a cargo cult is? It's not just about chocolate bars, I'll have you know.
But okay I'll byte. It's not just a cargo cult. It's a mass delusion built around impostor syndrome. The benefit that you feel you're getting from pre-commit hooks is the fear you have of pushing up a commit because you're afraid that everyone will find out that you can't code.
belavv@reddit
Hahaha
Cargo cult programming is more about someone not understanding something so including pointless comments, using design patterns that make no sense, etc. Precommit hooks live in a directory you'll never see if you don't want to change them or interact with them. So they don't affect the codebase in any meaningful way that could possibly be construed as cargo cult programming.
At least once a week a push code and send my ticket to code review. Then it comes back to me "failed the formatting check". Wasting the reviewers time and forcing me to context switch to get back to the ticket and fix the formatting.
If I set up a precommit hook that auto formatted any files with changes in them it would take maybe a second to run on each commit and save me and the other dev that wasted time.
I break the build more than anyone on our entire team. I'm not afraid of pushing bad code. I'm a fan of preventing bad code in automated ways. Precommit hooks can do that. Which reminds me that I keep meaning to set one up to avoid the problem that I mentioned.
CherryLongjump1989@reddit
Okay look you're being very honest here about some issues you're trying to overcome so I'm not going to pick on that, I never punish honesty. But your definition of cargo culting is fascinating, and wrong, so let's talk about that.
You should read Richard Feynman's 1974 commencement speech where he introduced the concept to the scientific community. Because where you've got it wrong is in thinking that cargo cult programming is an individual activity. The key word is cult, it means there are many participants. Feynman was condemning entire scientific fields of research, in particular education and psychology. He was condemning best practices that appear scientific on the outside, and are adhered to by thousands of people, but that are meaningless and don't actually prove any of the things that the researchers collectively believe that they prove.
This is why cargo cult programming is about group delusions -- beliefs in a process that everyone follows, but that doesn't actually achieve what they think it does. It's not about one guy who writes too many comments, or makes a bad decision with their software architecture.
belavv@reddit
https://en.wikipedia.org/wiki/Cargo_cult_programming
CherryLongjump1989@reddit
Right, that's what I'm trying to explain to you, but you just have to read past the introductory paragraph.
This would be pre-commit hooks in this case. Let's take a moment to address your probable concern about code comments.
Unnecessary comments are a cargo cult when they are a mandatory part of a baseless development process. Like when management forces the entire company to write code comments because he believes that well-commented code is more maintainable.
It's not, simply, when an individual programmer writes comments that he thinks are useful to himself, but that other people don't find useful.
belavv@reddit
At no point during any of that did you make a valid point for how pre commit hooks meet your own definition of cargo cult programming.
Plenty of commenters, myself included, have explained why precommit hooks are useful and their reasons for using them.
You are unable or unwilling to understand that, and insist that everyone who finds value in precommit hooks is trying to shove their entire ci/cd build into them and wasting five minutes every time they commit.
CherryLongjump1989@reddit
Point of order - I never called it cargo cult programming, only you did. I called it cargo culting. If your entire objection is that executing a hook is not a literal act of typing code, that's just on you.
The proof is in the pudding. This very thread, with the many people who fall into severe levels of cognitive dissonance after I pointed out the obvious -- that the practice of linting in pre-commit hooks is superfluous, redundant, and a drain on their own productivity. They make grandiose claims of the amazing things that it does for them -- saves them millions of dollars on CI/CD servers, avoids the criminal offense of failing a CI run, "automates" the hardest part of their job (checking if their code compiles). It's all been a whirlwind of nonsense.
belavv@reddit
Bless your heart
lifeliverDTN@reddit
"Competent" people are capable of occasionally forgetting to run type checking/linting/formatting checks prior to committing their code.
The productivity cost of getting an email 5 minutes after you push your code and having to context switch back, read the error message, swap branches, fix the issue, test, and push again is way lower than the cost of hitting that same error when you are about to commit the code when you still have the full context so you can resolve the issue faster.
Also the entire premise of this suggestion was that the new typescript compiler is fast enough that this is feasible. I don't think anyone is suggesting forcing developers to wait 15 minutes before they can
git commit, but 1-2 seconds is a perfectly reasonable cost to ensure that any committed code is considered correct from the perspective of tsc.CherryLongjump1989@reddit
You're trying to sell me on the idea that I should pay the 5 minute cost 100% of the time because if I don't, then 1% of the time I might lose 5 minutes. Your math doesn't math.
pala_@reddit
If you thought five minutes was that important you wouldn't be wasting everyones time with your dumbass arguments against automating a manual process that can be forgotten.
CherryLongjump1989@reddit
Weak. You deflected so hard, it's obvious you realized that your math doesn't math.
I don't care about what you do with your time -- it's obviously not important to you. I'm also not here to hold your hand and fly a little airplane into your mouth to get you to realize that you're wasting your own time with a cargo cult developer process.
programming-ModTeam@reddit
Your post or comment was overly uncivil.
CherryLongjump1989@reddit
I give as good as I get.
battlesqui_d@reddit
you're getting so hung up on 5 minutes this 5 minutes that. put all your CHEAP checks in your pre commit hook (formatting, linting, type checking, etc). now you don't need to pollute your commits with "chore: fmt" or whatever. you definitely don't need to run your ENTIRE pipeline locally before pushing.
also, nobody is FORCING you to use the pre commit hooks. if you're john 10x developer himself, by all means commit tax evasion and delete the hooks or use --no-verify on your commit. the premise of everybody arguing against you is that you can frontload cheap checks and not worry about them when you're getting your review.
CherryLongjump1989@reddit
Who said I'm hung up on it? You're using sleight of hand by claiming that a type check is fast and cheap? First of all we wouldn't even be here if it was fast and cheap. Second of all, the type check comes "for free" when you run your unit tests.
So what are you confessing to here? That you don't write tests, and you don't run tests, before you push up commits? That your unit tests are rarer than hen's teeth? That the codebases you work on professionally are little more than hello world demos?
Explain yourself. What are you doing wrong that makes your pre-commit checks something other than redundant, and simultaneously so incredibly fast that you can't even notice them running but yet so critical that it would be a literal calamity if the remote CI/CD server -- which is going to run all of the same crap anyway -- can't possibly deal with immense load you're putting it under.
programming-ModTeam@reddit
Your post or comment was overly uncivil.
General_Session_4450@reddit
It doesn't take 5 minutes to run it locally because you already have the dev environment setup, so you don't have to pay the cost of setting up the whole project from scratch like the CI pipeline has.
It takes 400ms to typecheck our project with the tsgo preview checker and around 3 minutes for the CI to set it all up and run the same check.
CherryLongjump1989@reddit
The number of times I've seen a sub-5-minute CI job in my professional life is equal to the number of times I've set it up myself. People literally run the full CI/CD in a pre-commit hook because they have a 45 minute build and some fucked up CI pipeline that might have 10 workers across 100 engineers.
shadowndacorner@reddit
Your perspective here is problematic. Let's use that word.
You don't need to wait for a CI run to complete to continue working. If the pre-commit hook takes on the order of a couple of seconds, it is essentially free relative to the network traffic.
Have you never heard of stashing?
azsqueeze@reddit
Right so running operations locally to make sure it's clean before moving to a CI/CD pipeline reduces cycles and ensures it remains fast and error free.
Things like local linting on files changed, type checking, or even in extreme cases testing on either pre-commit or pre-push ensures that errors doing get leaked into a pull request to annoy you since it does for whatever reason
sorahn@reddit
Why waste CI/CD money if you can have a pre-commit hook catch a stupid mistake?
CherryLongjump1989@reddit
It doesn't save money on CI/CD. All it does is save face for the one guy who doesn't bother to test his code before pushing it up for review. It hides the signal from the rest of the coworkers that oh, here comes an incompetent/distracted colleague who didn't test their own code, this code review is going to be a doozie.
sorahn@reddit
If the only thing ci/cd did was run my unit tests and literally nothing else, I could consider agreeing with you. There are a bunch of other things that are unrelated to the code working that can cause ci/cd to fail, and I'd rather have my machine spit those out immediately, instead of waiting for an email from circleci that says I forgot to delete an import that I'm not using anymore.
CherryLongjump1989@reddit
If you're talking about the emails that say that you've leaked your secrets to the open internet, I'm inclined to agree. It's best not to get those kinds of emails to begin with.
But you're not actually talking about that. You're not saying that things where the pre-commit hook is the last possible place to perform a check before the damage is permanent and severe. You're talking about the things where the CI/CD system on the build server is the last line. You're talking about getting an email which triggers some sort of OCD response from you, but doesn't actually mean anything.
sorahn@reddit
You make a lot of assumptions and type quite a lot to not say anything useful. Keep up the hard work.
schtinkelpecker@reddit
This is the dumbest thing I’ve read today
CherryLongjump1989@reddit
Congratulations.
Atraac@reddit
Because it takes <500ms to do so, instead of running entire Github Workflow(whatever else you're using), that pulls (maybe cached) npm packages, docker images, builds everything and then spams your slack(or you have to check manually).
CherryLongjump1989@reddit
No pain, no gain, as they say. If the only thing you're running before you push up a commit is a 500ms linter then you're going to end up with far more build failures far more often than you thought. Unless your build process is made out of hopes and dreams.
Nobody said you shouldn't try compiling your code before you push it to a remote build server. What they said is that it's stupid to do that one thing in a pre-commit hook, when there are in fact a bunch of other things including that that you should be running, together, throughout the entire process of writing your code. You know, like unit tests. It's stupid to do something that adds no value, even if it only costs you 500ms. It's still 500ms of bullshit.
Atraac@reddit
I'm not going to continue this because you clearly don't want a discussion, you want to show to everyone why you're right even though you know absolutely nothing about me, our project, needs or experiences. You'll grow out of that phase soon enough, good luck.
CherryLongjump1989@reddit
There's not much for me to grow out of considering I'm already a principal engineer and my job is to deal with hundreds of juniors who repeatedly come up to me with the same bad ideas that I've heard a thousand times before, but this time they think they're special.
AmorphousCorpus@reddit
holy larp
Atraac@reddit
We deploy to render via their git hooks so there's no workflow running inbetween. Also, I like to not commit shit into our repo.
CherryLongjump1989@reddit
You don't deploy to render via a pre-commit hook and if you did then we'd be entering a new level of fear and loathing in this thread.
Atraac@reddit
I haven't said I deploy to render via pre-commmit git hook. I said I deploy via THEIR hook.
CherryLongjump1989@reddit
And their hook is not a pre-commit hook. So there's no relevance to this discussion, is there?
aes110@reddit
If I understand correctly, this is specifically about the transpiling process? Was that an issue before?
At first i thought they were saying code written in ts7 would be so much faster, which doesn't make much sense
LiftingRecipient420@reddit
Correct.
Yes
Kapps@reddit
On larger codebases, or just codebases that trigger slow paths in the TS type checker, it could get very slow. This is used in your IDE too via the language server, so performance improvements make a big difference. On our codebase, go to definition often took 20+ seconds and code completion was barely functional. With tsgo, it's smooth (albeit at the cost of using ~10GB of RAM).
Urik88@reddit
Same, my former job used autogenerated types for a big Graphql schema which resulted in huge, extremely complex types, and the burden in the compiler and our editors was HUGE
Swie@reddit
oh the insane RAM usage is still a thing? great. Maybe in another 10 years they'll do another rewrite to make it actually performant... webdev really cannot beat the allegations.
CherryLongjump1989@reddit
You don't need it for transpiring, you need it for type checking. There are plenty of very fast transpilers that simply strip the type annotations away and turn the code into plain javascript.
lesleh@reddit
TS is basically a linter. Zero runtime overhead (for the most part). And there's a proposal to add optional type annotations to JavaScript itself so browsers can run the code (not type check the code) without having to strip the types first.
AnnoyedVelociraptor@reddit
The only thing with typescript that survives compilation is enums.
lesleh@reddit
And namespaces.
pjmlp@reddit
Both acknowledged as a mistake, and hence why nowadays they focus on being a linter and nothing else, other than maybe getting some JS features in advance with polyfills like Babel.
lesleh@reddit
They added a `--erasableSyntaxOnly` option that disables the code, but I doubt they'll make it default as it'll break existing code.
Mognakor@reddit
Given that ts7 also identifies a typescript standard and constructs that are valid in ts7 would error in ts3 it is correct to say "we're writing in ts7" just like you could say it about C++17
pjmlp@reddit
Kind of, the team learnt not to be another Dart or CoffeeScript, hence why except for enums and namespaces, Typescript is basically a linter.
The only "language" changes are always related to improvements on the type system, and ways to generate JavaScript code that are less painful with all the tricks that one can pull in a dynamic language like JavaScript.
And just like Babel, provide features in advance than can be polyfilled (not all can, if they require JS runtime changes), but are already mid way on the JS standard process.
Mognakor@reddit
It's a "linter" that refuses to produce code if it fails and over versions it gets better at removing false positives.
CherryLongjump1989@reddit
TS7 does not introduce any new language features, so all the more reason you are not programming "in" ts7.
slaymaker1907@reddit
I’m kind of surprised they were allowed to use Go. When I was at MS there was a big bias against Go because it is Google and Google is known for killing things off.
pjmlp@reddit
Even more surprising is that Microsoft has gone back to Java as well, they have their own OpenJDK distribution and were the contributors for Windows ARM support for the OpenJDK.
Since Satya took over, Microsoft became a polyglot shop, go to https://devblogs.microsoft.com and check the languages drop down.
The tragic part about using Go instead of Native AOT, given the Typescript architects background, is that kids that want to contribute to Typescript will learn Go, while .NET team complains about lack of adoption on macOS/Linux.
A1oso@reddit
That might have been true 10 years ago, but by now Go is big enough that it can't be killed.
Rust also survived – and is thriving – after Mozilla laid off most of the Rust team in 2020.
pjmlp@reddit
Because most of the key contributors are now working at AWS, Google and Microsoft.
Example, the main drivers for Rust on the Linux kernel, are from Google and Microsoft.
skandaanshu@reddit
Go is stable enough and with huge userbase that goog nixing it won't matter at this point. Other huge companies from FANG using it could maintain a fork alive. gcc also maintains an independent compiler gccgo, though it isn't used extensively by companies iirc.
Delta-9-@reddit
This is a true statement, people, quit down voting truth just because you hate it.
Darkoplax@reddit
I thought the main benefit is VSCode becoming faster ?
These-Maintenance250@reddit
why would they implement the transpiler in Javascript in the first place...
airemy_lin@reddit
10x for compilation and type checking yes.
well-now@reddit
All of TypeScript is about developer experience :)
airemy_lin@reddit
Actually, yeah. My comment was redundant lol
TechWizardJohnson@reddit
Always interesting to see how TypeScript evolves without breaking everything. Curious if 7.0 brings more performance improvements or if it’s mostly type system tweaks this time.
programming-ModTeam@reddit
No content written mostly by an LLM. If you don't want to write it, we don't want to read it.
MedicOfTime@reddit
The tech wizard has managed to avoid all TS news over the past year…
AlyoshaV@reddit
I believe it's a bot, or maybe a user copy-pasting an LLM without doing any research
germanheller@reddit
the Go rewrite compile speedup is the headline but the real win for large monorepos is incremental checks that actually finish. Waiting 45s for tsc --noEmit to rescan after a one-line change was the worst part of 6.x.
programming-ModTeam@reddit
No content written mostly by an LLM. If you don't want to write it, we don't want to read it.
KnifeFed@reddit
Wow, I wish all subs did this.
Kinsbane@reddit
oh cool
... anyway, i still don't give a fuck
umtala@reddit
No thanks, wake me up when I can use the same API. TS6 works just fine and this is going to break everything that uses the 'typescript' module.