4 ms·

No idea. Matt Pocock has a much better cheat sheet for tsconfig configurations and his is set as es2022. https://twitter.com/mattpocockuk/status/17016192406864

No idea. Matt Pocock has a much better cheat sheet for tsconfig configurations and his is set as es2022. https://twitter.com/mattpocockuk/status/1701619240686485799 https://twitter.com/mattpocockuk/status/1701619240686485799

fortunateregard 3y ago
Link to full cheatsheet: https://www.totaltypescript.com/tsconfig-cheat-sheet https://www.totaltypescript.com/tsconfig-cheat-sheet
- sedro 3y ago
  This cheatsheet would have you publish dist/*.{js,d.ts}. Presumably you would use "files":["dist"] in package.json to exclude sources from being published. The OP recommends to additionally package src/*.ts along with sourceMaps and declarationMaps. What's actually the best practice here?
  - antipotoad 3y ago
    I poke around in node_modules with some regularity (often in combination with the debugger) and it’s always nice to find actual source files, not just source maps.
herpdyderp 3y ago
I prefer to leave lib empty, it’s always caused me problems.
n2d4 3y ago
Browser support for ES2015 is about 95% [0], while most ES2022 features sit at around 90% [1]. You can find the individual benchmarks on compat-table [2]. Some, but not all of these, are transpilable/polyfillable (refer to compat-table). Edit: Those numbers are weighted by global usage. [0] https://caniuse.com/es6 https://caniuse.com/es6 [1] https://caniuse.com/?feats=mdn-javascript_builtins_array_at,mdn-javascript_builtins_regexp_hasindices,mdn-javascript_builtins_object_hasown,mdn-javascript_builtins_error_cause,mdn-javascript_operators_await_top_level,mdn-javascript_classes_private_class_fields,mdn-javascript_classes_private_class_methods,mdn-javascript_classes_static_class_fields,mdn-javascript_classes_static_initialization_blocks https://caniuse.com/?feats=mdn-javascript_builtins_array_at,... [2] https://kangax.github.io/compat-table/es2016plus/ https://kangax.github.io/compat-table/es2016plus/
- lolinder 3y ago
  When we talk about "modern browsers", we're not talking about usage percentage, we're talking about browsers released in the past few years. If you need to support browsers older than that, that's great, but we don't call those modern browsers, that's legacy support. Most modern browsers are evergreen, so targeting es2022 would be fine for most users. The exception is Safari, which is slower to incorporate new features and doesn't roll out its updates nearly as quickly as Chromium-based or Firefox, but even they have had es2016 support since 2016.
  - nwienert 3y ago
    Also Safari greatly picked up pace a few years ago and honestly it’s hard to categorize them as behind anymore. They lead in several areas, and have caught up in most.
  - n2d4 3y ago
    Sure, but the reason why browser compatibility is being measured is to quantify that notion of "modern". You can then use that to make your own decisions; if you're working on a high-tech video streaming platform for kids you can probably safely ignore the 5%, but if you're providing information on behalf of the government you might need to support much more than that.

fortunateregard 3y ago

Link to full cheatsheet: https://www.totaltypescript.com/tsconfig-cheat-sheet https://www.totaltypescript.com/tsconfig-cheat-sheet

sedro 3y ago
This cheatsheet would have you publish dist/*.{js,d.ts}. Presumably you would use "files":["dist"] in package.json to exclude sources from being published. The OP recommends to additionally package src/*.ts along with sourceMaps and declarationMaps. What's actually the best practice here?
- antipotoad 3y ago
  I poke around in node_modules with some regularity (often in combination with the debugger) and it’s always nice to find actual source files, not just source maps.

herpdyderp 3y ago

I prefer to leave lib empty, it’s always caused me problems.

n2d4 3y ago

Browser support for ES2015 is about 95% [0], while most ES2022 features sit at around 90% [1]. You can find the individual benchmarks on compat-table [2]. Some, but not all of these, are transpilable/polyfillable (refer to compat-table). Edit: Those numbers are weighted by global usage. [0] https://caniuse.com/es6 https://caniuse.com/es6 [1] https://caniuse.com/?feats=mdn-javascript_builtins_array_at,mdn-javascript_builtins_regexp_hasindices,mdn-javascript_builtins_object_hasown,mdn-javascript_builtins_error_cause,mdn-javascript_operators_await_top_level,mdn-javascript_classes_private_class_fields,mdn-javascript_classes_private_class_methods,mdn-javascript_classes_static_class_fields,mdn-javascript_classes_static_initialization_blocks https://caniuse.com/?feats=mdn-javascript_builtins_array_at,... [2] https://kangax.github.io/compat-table/es2016plus/ https://kangax.github.io/compat-table/es2016plus/

lolinder 3y ago
When we talk about "modern browsers", we're not talking about usage percentage, we're talking about browsers released in the past few years. If you need to support browsers older than that, that's great, but we don't call those modern browsers, that's legacy support. Most modern browsers are evergreen, so targeting es2022 would be fine for most users. The exception is Safari, which is slower to incorporate new features and doesn't roll out its updates nearly as quickly as Chromium-based or Firefox, but even they have had es2016 support since 2016.
- nwienert 3y ago
  Also Safari greatly picked up pace a few years ago and honestly it’s hard to categorize them as behind anymore. They lead in several areas, and have caught up in most.
- n2d4 3y ago
  Sure, but the reason why browser compatibility is being measured is to quantify that notion of "modern". You can then use that to make your own decisions; if you're working on a high-tech video streaming platform for kids you can probably safely ignore the 5%, but if you're providing information on behalf of the government you might need to support much more than that.