browserslist In Typescript config

[danny007in]

browserslist is a library that allows you to specify the range of browsers you want to support in your web application. https://github.com/browserslist/browserslist/issues/751 config shared value in target

{
  "compilerOptions": {
    "target": "es2018",
   }
}

to

{
  "compilerOptions": {
    "target": "browserslist",
   }
}

[ai]

It will be nice to have unified target option across all tools instead of having different formats in different configs.

Why not use Browserslist config since it has support in Autoprefixer and Babel?

[fatcerberus]

Please follow the issue template for feature requests if you don't want them to be immediately closed by the maintainers.

That said, this isn't really feasible - TypeScript has the type definitions for built-in functions in bundled .d.ts files and the type definition machinery is not nearly granular enough to make this work; in particular, there's no support for conditionally defining types. So you'd need hundreds of .d.ts files, one for each browser version, and the TypeScript npm package would end up looking like this: 🐽

[danny007in]

@fatcerberus config shared value in target

{
  "compilerOptions": {
    "target": "es2018",
   }
}

to

{
  "compilerOptions": {
    "target": "browserslist",
   }
}

[fatcerberus]

@danny007in Yeah, I get that - my point was that that doesn't mean anything without TypeScript also having the ability to conditionally exclude types based on the browserslist config, which simply isn't practical today.

[RyanCavanaugh]

We've discussed this before and it's a huge amount of complexity for what is ultimately a very small number of concrete decisions that are much easier to reason about in isolation, especially in the modern era of browsers where you can basically get away with something like ES2015 and never think about it again. target only affects downleveling, so you're free to use a different downleveler if directly consuming a browserslist is a hard requirement for some reason.

[jfbrennan]

The proposal here reflects real world development. No team targets a specific version of ES - they target browser versions based on what their web traffic analytics tell them.

In most projects developers get to write modern JS source code and have it turned into whatever their users' browsers need it to be. The go-to tool for configuring this is browserslist and virtually all modern frontend tools incorporate that into their build scripts. TS doesn't?! I fully expected it to until I went down this rabbit hole and found my answer. My patience for TS was at like 1%. It just reached 0.

[typescript-bot]

This issue has been marked as "Declined" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[padcom]

No team targets a specific version of ES - they target browser versions based on what their web traffic analytics tell them

@jfbrennan That's a very short- and one-sighted view on code. JavaScript runs not only in the browser but also in node.js and other runtime environments (e.g. embedded interpreters). Sure, the browser is the most popular one, but still not the only one. TypeScript being a transpiler needs to be able to target officially supported language levels, not just one type of environments, even if it is the most popular one.

[jfbrennan]

@padcom Using browserlist is not short-sighted - a necessary evil in web development - but not short-sighted. So, it's perfectly reasonable for developers to ask TS to add support for it, especially considering how much polyfilling and monkey-patching TS already does when building for older targets. This is an opportunity for TS to help simplify the insanity that is modern JavaScript development, a situation TS has made worse, so the least it could do is have support for browserlist like so many other build steps.

[AMorgaut]

That's a very short- and one-sighted view on code. JavaScript runs not only in the browser but also in node.js and other runtime environments (e.g. embedded interpreters)

@padcom the proposal made in this issue doesn't force to use browserslist for all projects It still lets the possibility to target es2018 or whatever for any non-browser target project

[padcom]

@AMorgaut Anything that makes Typescript specific to a platform or makes a distinction between platforms, is going to violate the purpose Typescript serves. If you need to transpile your code further chain something after TS has removed the types and use tsc only to remove types and to do type checking.

[jfbrennan]

I find teams do one of two things:

• Set their target to something old, like es5, and knowingly or unknowingly (I'm willing to bet it's most often the latter) ship a bundle that's been bloated with all the TS polyfills and helpers
• Add additional tooling, like you've suggested, that takes TS output and runs it through yet another process (Babel) to get *fingers crossed* a more targeted bundle based on real world needs

In the end many teams have no idea what these tools are outputting and what costs they've added in terms of performance, build duration and reliability, and debuggability. Most teams unfortunately just muddle through this noise until they have a stable working project and can focus on the real work.

Putting aside its benefits, TS has, objectively, further complicated the web landscape, yes? So a project of this size and with corporate support should take the opportunity to help alleviate some of the pain and complexity it has introduced by adding support for, like so many other tools, the browserlist config. TS already has many build options and I don't see how browserlist would violate TS philosophy anymore than say reactNamespace or jsxFactory or the SQL or CSS plugins or CommonJS/AMD/UMD interop.

[padcom]

Please note JSX is part of the Typescript grammar. It is a conversion from one syntax to another - like decorators or many other TS features.

Influencing the transpilation with some external tool like browserslist is in my opinion one step too far. There are pre-existing tools for that. In essence, Typescript is not Babel nor Vite nor Parcel. It's a transpiler that is meant to, primarily, remove types from the .ts source and convert some newer constructs to lower versions of ECMAScript (if possible). It's the ECMAScript version that the transpiler targets - not a specific environment the code will later on run in. That's the job of Babel and esbuild.

I know the difference is subtle and that it might be difficult to understand for the untrained eye, but it is quite a substantial one. If you want browserlists-based transpilation you should use something that is meant for it. I, personally, use Vite/esbuild, but Babel is also an option. As a bonus, my projects benefit from standards (like module bundling and assets processing) that Vite provides.

[padcom]

I have to add one more thing to it, though. The JavaScript ecosystem is messed up totally. It is true, that most teams struggle to get the final build just right and, in most cases, they settle for it works. The reason for it is quite simple: it's the fastest evolving and the most popular programming language on the planet. With that in mind, people want to use the latest and the greatest even if the target platform doesn't support it.

You will not find it anywhere else (with the exception of C/C++, but everyone knows it's a controlled mess there). Languages are standardized, and you target a specific version of the runtime capable of running your code. There is no better example of it as with Java, which was frozen for many years and that turned out to be the biggest selling point for it.

With ECMAScript it should be, in my opinion, the same. You shouldn't think of Typescript as a silver bullet that will give you all the latest and the greatest while taking care of all the mess that's been introduced throughout the years to the ecosystem and to the platform itself. You shouldn't think of targeting this or that browser but rather a specific version of ECMAScript. The fact that browsers lack in implementation of certain latest features of the standard means you shouldn't be using them. Period. Let them finally rest in peace.

Just like Internet Explorer...

It all started ages ago with Microsoft. They wanted to make their own version of JavaScript and the runtime, so MS is in point of fact responsible for starting this madness. I remember everybody was anxious about that, pointing out that it will force users to use one browser for a set of sites and another one for a different one. That's how jQuery became a thing because it introduced a layer on top of those inconsistencies. I feel that we've gotten so used to the fact that things are wrong that if someone wants to fix it now (like the original culprit - being Microsoft in this case) we object and ask for more.

ECMAScript is the new jQuery. In jQuery you could target multiple browsers, but all the latest and greatest wasn't available to you - just a subset that was possible. It is exactly what ECMAScript does nowadays - it gives you a subset of the capabilities of the browser and server-side that you are guaranteed to be able to use. If we continue down the rabbit hole of Babel and esbuild, we will IMHO never be able to dig ourselves from this shithole that we're in, and no team will ever be able to make a conscious decision how to configure their projects.

Please also note, that transpilation is just 1/4th of the actual problem. New frameworks that allow you to do the same thing in a different way are popping up like mushrooms on a warm summer day after a rainy night. Last time I counted it was over a 100 of those and not 1 or 2 being in the lead. And that is just about HTML generation and manipulation. On top of that, you get CSS transpilers, CSS frameworks and even new source file formats (.svelte, .vue - you get my point).

Do I think it's wrong? Hell yeah! Can it be stopped? Probably not. I think it's a bit like democracy and open markets. Those are the two worst things out there, but nobody came up with anything that's better.

I think that, in the end, in software development there is no substitute for thinking and experience. It wasn't long ago when everybody was starting their adventure by jumping in bed with one of the frameworks (most predominately with React) with no regard to the basics (HTML, ECMAScript and CSS). Problems that could be solved by learning about those lead to the creation of stupid ideas like Redux. If you wanted to get a job, nobody would ask you if you can program, but they did ask if you knew React and Redux.

Programming is hard. It's one of the hardest disciplines I know. Getting it done is not simple, and getting it right is extremely difficult. No amount of help from a framework or transpiler can substitute the learning process that needs to happen for an individual to consciously know what and how they are doing. I have a strong feeling that a large amount of advertisement has gone into making shitloads of untrained programmers that are more and more frustrated and hate their job. I strictly remember when people were not hired for what they can do, but for what they think they can learn. It was way more important to get a prospective coder than to get an efficient and motivated coworker. I always hated that, and I still do. The tides are turning now and what seemed to be a lost battle the market verifies now with no mercy whatsoever.

My point is, that if you don't want to invest time into learning to set up a project right and to understand the difference between targeting a browser vs a language version, you might want to consider a career in a less demanding profession. I know many guys who really wanted to become programmers and were serious about putting the time and effort in doing so. But for every 100 wannabes there is 1 or even less that made it and understands what the heck they're doing - simply because it is hard and not everyone is cut out to be a professional software developer.

What's even more prominent is that the masses of mediocre wannabes now define what normal means. That is completely absurd, but that is the world we live in. People no longer think when they write code - they code. Period. More often than not, it leads those who did invest time and effort into taking things seriously to be frustrated and depressed. Luckily, like I mentioned before, the industry heals itself and my hope is that more and more quality will prevail over quantity.