[mdaniel]

Fun fact: the "compilation" step in my company's React project is the biggest consumer of CI minutes by far across our entire organization, beating out every one of the Maven compile and test loops

But, since the devs don't care, there's only so much finger wagging I can do

[kevingadd]

Over the course of a month or two the time taken to compile a single .ts file in our codebase climbed from 'too small to measure' up to '7 seconds'. It eventually turned out that a single type definition in the file was causing all typechecks to become incredibly slow. Getting timing data out of build tools like rollup was brutal, and editors with tsc integration like vs code/sublime text would just lag and misbehave. This regression had occurred without anyone noticing, because we all just assumed it was normal for 'build and bundle our typescript' to take a long amount of time despite how simple our code was.

[spookthesunset]

I have to say, for some reason one of the more satisfying things to do is dramatically speed up a lengthy build. It’s hard to beat taking a build that runs forever and making it take a few seconds.

I don’t know why. Perhaps it’s because it’s something you and your peers use constantly so when it speeds up the quality of life for all in the shop improves. I mean, it’s not often you get to make an improvement to your project that directly affects everybody working on it.

Perhaps it’s because of the challenge and that most developers absolutely hate fucking around with the build system. Example: the parent poster. Build systems are can be pretty archaic but have a ton of features that most people don’t exploit.

Perhaps it’s because it is easy to timebox and has a readily apparent set of diminishing returns. You can generally make a single change, push it to production and if that is the only change you made you’ve still added value.

Perhaps it is because almost all of the changes you make don’t alter how the end user (other devs) use the build system. Short of swapping the build system entirely most of the time everything you do changes nothing for the developer.

Perhaps it is because it is a good distraction from whatever it is you should be working on. You can squeeze it into spaces where you don’t have much in the pipeline or need to think something through.

Whatever it is, I love fucking around with build systems.

[irrational]

And that is one of the main reasons I hate build systems. If I have to use a build system it had better work perfectly the first time and every time, never slow me down, and never ever require any fiddling or maintenance.

[abraxas]

To me that's a definition of make work. A good development ecosystem should require no wizardry to make it perform well. And it adds absolutely zero value for the end user of your product. This is why myself and 99% of developers abhor Rube Goldberg build systems like those that permeate JS.

[phist_mcgee]

A great craftsman will take care of his tools and seek to use the fewest number of cuts to achieve the desired result.

Improving builds/dev environments is taking care of your tools.

Also, citation needed on the 99%

[tracker1]

Had similar issues with linting/formatting... switched to rome.tools a couple months ago and really happy with the change. I'm really looking forward to that project's goals too.

[phist_mcgee]

Hasn't rome had some dramas in the past?

I was under the impression that since it's such a large project, it is quite a risk to use it atm before it's fully ready.

Happy to be proven wrong.

[tracker1]

I'm not really sure, I haven't followed the development that closely... I know I tried it... and it was pretty close... when I was ready to switch, had done some testing, and had to adjust several of the defaults to be closer to the existing linter config. That said, the reformat/lint-fix was so fast, it wasn't that big a deal. Did it in two commits, one with just the linter config, another with the reformats in a separate commit.

The whole project can be scanned and reformatted and lint-fixes applied in under a second... the eslint config with TS took several seconds... as a precommit hook it felt pretty painful in practice, now you don't even notice it.

If they do as well for build options (once added), I'll be very happy indeed.

[phist_mcgee]

The build step is the hardest of all.

Just look at vite, it's amazing progress, but getting it to work with legacy codebases is a nightmare.

Not having proper require support is a real killer.

My bet is in 5 years we'll have massive buy in to these one-stop tools, but until then, they don't fit the real world as well as i'd like.

[fennecfoxy]

Granted, we have all moved from receiving updates to languages/frameworks once every 1-3 years (C# etc) or C++ with 3-8 years and instead get them monthly (sometimes even daily).

Devs from the past who wrote chunks of FORTRAN that sat on a "dusty 386 in the basement for 30 years" are still around, what do they think of the constantly evolving field/goalposts vs more traditional, slower release cadence of languages/frameworks/software in general (afaik; I wasn't around for it).

[thex10]

> It eventually turned out that a single type definition in the file was causing all typechecks to become incredibly slow

I've love to read a blog post about this.

[h1fra]

It's a common pitfall yes, especially bc of big libraries like gcloud (https://news.ycombinator.com/item?id=32307019)

Build CI should be configured with a very aggressive upper limit to catch those regression but it's often forgotten; even I don't do it often while I have been bit more than once.

[KolmogorovComp]

If you can turn that time into money spent and show it to them and the management, it could change.

If in terms of money it’s not significant, for the company it makes no sense to devote costly labour time to speed it up.