@@MrEliteXXLbecause when you use them the ts compiler emits extra code. This flag disallows all ts syntax that emits extra code. The benefit with using this flag is that you can now run your code as is without any compiling or bundling in runtimes that know how to ignore ts types (like the newest nodejs).
and it would be convenient to just port my TS code to nodejs. but nope. nodejs just wants a quick strip types solution and be done with it. if you understand TS you understand the massive success of parameters props. and if you care about users you would support it. bad job nodejs team.
@@JarheadCrayonEater please tell me what you mean. in my mind maintence is easier because i can change name and type in one single place instead of two. i need a concrete example what you mean
@@JarheadCrayonEater I mean, I agree with this in general, but this is specifically about constructor parameters, which is not considered to be "wrong" in any other programming language.
@@omri9325 classes are not DTOs exclusive at all. in fact DTOs in many cases are plain objects supported by an interface. DI containers are the main loss
@ If it's an object created by an object literal and not custom constructor you would call it a plain object and not DTO. When people say DTO they *usually* mean what it means in languages like C# or Java where to make a simple data transfer object to serialize/deserialize you have to create a class. In javascript+ts using an interface with object literal is perfered for this, and creating a DTO class is an anti-pattern
TypeScript is not a language, it's a type checker, so it goes against the modern standard that TS shouldn't be involved in runtime issues. Also enums are a little weird. You can code a typesafe Enum equivalent if you really want, or get similar results with simple things like objects.
You still have an enum alternative. Something like this should work: const myEnum = { value: "value", value2: "value2" ...} as const; type MyEnumType = typeof myEnum[keyof typeof myEnum];
@@robertsandiford6223to me it is a language since I don't consider Javascript to be up to the task of scaling software. Typescript gives you options to keep you code clean. And it shouldn't matter from that perspective whether they do stuff runtime VS compile time. Enums make your code more stable.
parameter properties was a great achievement of C#, like async/await also. typescript copied lots of features. these features are such a success because they are very intuitive, very much used and very anti-boilerplate. nodejs team seems not to understand. they can support it. but i guess they like a "clean" "no effort" type-strip solution. sad.
Wasn't sure what your problem with enums is, I like them, particularly as semantic keys. But, I went and found your video on enums, as const from now on.
Typescript, the only language where a simple keyword like enum is a pitfall and beginners are encouraged to create weird boilerplate in its place. And yet enum seems to work fine and the weird boilerplate throws syntax warnings.
@mattpocockuk yes but people don't pretend they are good But I read more about it and there's nothing actually wrong with typescript enums as long as they have a string definition, so that's cool
Constructor parameter auto assignment is actually something I like. I guess being able to disable enum is a win, but yeah, shame about constructors. Type strippers (SWC) could handle the auto assignment, but I assume the intent is to keep Node aligned to what JS annotations will be.
but those parameter properties are very useful, because they reduce the amount of code i have to write. without those I'd need to assign each property manually in the constructor. i would also have to keep property and parameter name in sync manually, because I like consistent naming. any thoughts? or am I wrong? how can I otherwise reduce work and boilerplate if not with parameter properties? if babel supports it with plugins, so should nodejs. no excuse.
@@robertsandiford6223 nodejs should adopt all TS feature because there are TS devs who use them and they want to use them when they switch to vanilla nodejs also. That is a very practical down to earth argument, would you agree? What point would strictly following ecma spec have in this case? I agree that nodejs JS should follow ecma spec because its JS. But nodejs TS should follow TS spec. These are 2 different things.
@@weirdwordcombo TS has moved away from runtime features as that would create a clash between TS runtime features and new features added to JS itself. E.g. JS may one day have its own enums. We're not going to see further development of TS runtime features and support for them.
It seems they dislike that those are checked runtime. But I have the same question. Because to me it is more important write clean code with the tools a language gives me than how the language supports such a feature.
@twigsagan3857 same. And I think all of this is mostly about Node, and NOT browser. TypeScript doesn't really do anything at runtime in a browser... it's transpiled...
I guess partly it's because union types exist that can do the same thing without any extra syntax overhead, while also still having intellisense capabilities. Sometimes enums can also be transpiled differently depending on how they're written. I can't remember exactly, but say if you wanted to get all the values of an enum type via Object.values(), it will return essentially the same values twice, but with the keys and values swapped. Something like: { 1: "ValueA", 2: "ValueB", "ValueA": 1, "ValueB": 2 }
@@twigsagan3857 No, it is because it does not map to a javascript construct. The typescript compiler extra code for enum. This is an issue for type strippers like the new option in node: --experimental-strip-types
I didn't know constructor parameters are possible like that, that's pretty cool. I guess if I'm already transpiling my stuff i can make an exception for it.
Erasable means it can be stripped at runtime. Non-erasable typing actually affects how your code behaves, erasable typing is only visible to the developer/typescript compiler. Enums are non-erasable, as code gets generated in its place; they're a form of syntactic sugar.
@@mattpocockuk what does too implicit mean? why is that bad. i think it is more important that it is super intuitive. than it can be implicit, no problem. future proof? nodejs needs to support it if it wants to serve its user base.
@ Too implicit means that it's not documented as part of MDN's classes. It's syntax that doesn't describe itself - you need to read the TypeScript docs to understand what it's doing. If TS wants to live out its future as 'JavaScript with types', it needs to get rid of these strange hangers-on.
You should probably explain what's the problem with enums and namespace rather than just calling them weird. I still don't understand what this flag for tbh. If you opt to disable, then what's the alternative?
I think TS went bit overboard with the enums, including different behavior of numbers and strings that eventually resulted breaking change in TS 5. I personally would have preferred enums to cover only auto-incrementing integers with optional redefines without backtracking and other jazz.
Honestly I've been using a custom Enum class for quite sime time now. Mainly because I frequently needed 2-way bindings for a specific project and enums can't be sirect class properties... (WHY)
Because: - You need to ship source maps to make it work - It ties Node in somewhat to TypeScript's runtime syntax, which is not a dependency they want - especially when the TS themselves are signalling that it's not the future of TS.
@yoyo this flag doesn't disable the ability to pass things into a constructor, it just disables the shorthand syntax for creating class properties directly through the parameter list of the constructor. You can still do constructor injection just fine.
@@mattpocockuk sorry I was using my phone for the previous answer. I was wondering what would be the best syntax when using DI, if using "private readonly" as constructor params is not a best practice anymore ?
Hmm, now we're at the point where it actually matters whether a private class property gets transpiled from `private foo` to `#foo` or not. I wish that was the case, there definitely could be at least a flag for that behaviour, but given my past lack of success suggesting such things on the typescript repo I think I'm better off just rewriting my code myself. Not sure yet what I'm going to do about methods that I need in my unit tests, but want to keep private in the production version :\
I feel like I'm such an outlier in that I actually really like Namespaces. I don't get the hate - I find it really useful for semantic compartmentalization where names of exports get really dense and start to overlap. given that, I'll echo other people's comments: I wish it were a little more granular, but I get how that doesn't help with the new node type stripping.
For me enums, namespaces (and modules + references) are obvious nonos from day 0, but private and protected properties seems good practice to use together with _ prefix. Or am I somewhere wrong?
@mattpocockuk Yeah I know but still are they really bad practice to use? In your code, do you do this implicit assignment or assign values explicitly in the body of the constructors?
@mattpocockuk `public` vs. `Object.assign` - This is a minor thing but underlying a major tradeoff: In my company, codebase readability is probably worth more than direct portability across the runtimes and configurations, or do you think that it is the other way?
Besides the fact that JavaScript has more robust built-in support for private class members now: No, that's not what it means. This only affects constructor properties. In TS, the code class Foo { constructor(private bar: string) {} } is an equivalent shorthand for class Foo { private bar: string; constructor(bar: string) { this.bar = bar; } }
I'm so tired of TS enums and all the people I work with that keep using them for EVERYTHING. You inevitably end up with someone making MyEnum and MyEnumButBigger because you can't simply extend one enum from another, y'know something that is trivially easy if you just use a string literal union instead which is what 99% of enums usages should be. And please stop with the "but enums are easier to refactor nonsense", in >5 years working on large TS monorepos the amount of times I've had to refactor the value of an enum/string union in already deployed production code is ZERO. Also, fun fact, it STILL essentially says in the TS docs: "probably don't use TS enums unless you have a good reason to and know what you're doing".
stop saying DTOs are bad in comments. I use tsyringe as DI container. massive boilerplate incoming if i use this flag I guess. horrible. classes are used for much more than DTOs. this is a major issue if you are forced to use nodejs with native typescript support I guess. nodejs should support transpilation plugins like babel.
@@aleksander5298 When it became skill issue, if the issue with good software is because of enums... liberal crap talking about sooner or later we are doomed, so remove enums, because u don't have anything smart to do in world, where all the same apps that are just rewritten in more baby languages...
The "pitfalls" of enums in typescript are a non issue for the vast majority of users. I think talking about enums like they're dangerous or bad is disingenuous because they're neither. Sure it's probably good to be aware of them, but once again it will not impact the overwhelming majority of users. I've never heard you say you didn't like constructor parameter properties, but I also don't get why you wouldn't. It's similar-ish to C#'s primary constructors which isn't inherently bad either. Sure there's cases where you want to have private back fields and public facing getters, but if you're making POCOs or I guess in typescript it would be POTO or anything really that doesn't need fine grained control it's a nice way to not have to write all of the properties out, then the constructor function with it's parameters then writing the body of the constructor to do the re-assignment for all of them. Idk I probably would never use this flag, but I guess for all of you who take issue to these things good for you lol.
So, Node, after more than a decade of existence decided will implement typescript but doesn't, so to fix it, typescript itself changes Wouldn't it be better to, ACTUALLY implement typescript instead of just rename the extensions form "ts" to "js" and pretend everything is fine?
No, because I think everyone involved (Node and TS team) see this as a possible sea change moment to get rid of some features that they're not interested in supporting. TS's future is as JS + Types, not as its own language with runtime features.
Don't like it. There are constructive code generations. While enums (in TS) and namespaces aren't constructive, constructor parameters are. Also wish we had type to code generation, something like type MyType = 'foo' | 'bar'; let x: MyType; if (element.dataset.id in MyType) x = element.dataset.id; Because manually writing element.dataset.id === 'foo' || ... Is tiresome and error prone when you extend MyType later.
This is a terrible update. I love enums and constructor property promotion and will NEVER stop using them (we use DI that depends on this). I don't get the hate towards enums, they're very useful. Namespaces I'm ambivalent about but they make more sense for a utility module over a class with static methods. I see this update as a regression.
Nothing, it's just a flag which you should keep out of your config. I don't see the TS team removing this stuff outright because of backwards compatibility, especially considering this is Microsoft and they never remove anything (see about not being able to name a file "COM")
Flag is cool, but I love constructor properties...
I use them all the time… also I don’t understand why they should be considered under this flag
@@MrEliteXXL agreed with both, but I'm open to being convinced otherwise
Agreed, it goes well with NestJS
@@MrEliteXXLbecause when you use them the ts compiler emits extra code. This flag disallows all ts syntax that emits extra code.
The benefit with using this flag is that you can now run your code as is without any compiling or bundling in runtimes that know how to ignore ts types (like the newest nodejs).
tbh, I really like the class constructor parameters. Its so convenient to use it that way.
and it would be convenient to just port my TS code to nodejs. but nope. nodejs just wants a quick strip types solution and be done with it. if you understand TS you understand the massive success of parameters props. and if you care about users you would support it. bad job nodejs team.
Convenience in programming is lazy, and almost always ends in a maintenance nightmare later.
Do it right, the first time.
@@JarheadCrayonEater please tell me what you mean. in my mind maintence is easier because i can change name and type in one single place instead of two. i need a concrete example what you mean
@@JarheadCrayonEaterwhat approach would be more right then? Because as I see it the only alternative is that you redundantly define variables.
@@JarheadCrayonEater I mean, I agree with this in general, but this is specifically about constructor parameters, which is not considered to be "wrong" in any other programming language.
I’m just sad for the constructor property promotion. It’s just so useful for DTOs!
😂
I guess it can help people understand that DTOs an anti pattern in javascript
a must for all the DI container libs out there. in fact anytime you have a class you very well would like to want them.
@@omri9325 classes are not DTOs exclusive at all. in fact DTOs in many cases are plain objects supported by an interface. DI containers are the main loss
@ If it's an object created by an object literal and not custom constructor you would call it a plain object and not DTO.
When people say DTO they *usually* mean what it means in languages like C# or Java where to make a simple data transfer object to serialize/deserialize you have to create a class.
In javascript+ts using an interface with object literal is perfered for this, and creating a DTO class is an anti-pattern
but the class parameter properties thing is awesome, though
Should be in js not ts.
what bizzaro world is this? everyone wishes they had enums in languages that dont
TypeScript is not a language, it's a type checker, so it goes against the modern standard that TS shouldn't be involved in runtime issues. Also enums are a little weird.
You can code a typesafe Enum equivalent if you really want, or get similar results with simple things like objects.
You still have an enum alternative. Something like this should work:
const myEnum = { value: "value", value2: "value2" ...} as const;
type MyEnumType = typeof myEnum[keyof typeof myEnum];
I'd love enums in JavaScript. But TS enums are odd.
@@akikadzeThat's a lot more work than an enum
@@robertsandiford6223to me it is a language since I don't consider Javascript to be up to the task of scaling software. Typescript gives you options to keep you code clean. And it shouldn't matter from that perspective whether they do stuff runtime VS compile time. Enums make your code more stable.
parameter properties was a great achievement of C#, like async/await also. typescript copied lots of features. these features are such a success because they are very intuitive, very much used and very anti-boilerplate. nodejs team seems not to understand. they can support it. but i guess they like a "clean" "no effort" type-strip solution. sad.
They should be in js as they are a runtime feature. Ts is best as only a type checker.
Wasn't sure what your problem with enums is, I like them, particularly as semantic keys. But, I went and found your video on enums, as const from now on.
Typescript, the only language where a simple keyword like enum is a pitfall and beginners are encouraged to create weird boilerplate in its place. And yet enum seems to work fine and the weird boilerplate throws syntax warnings.
Lol TONS of languages have pitfalls a lot worse than enum
@mattpocockuk yes but people don't pretend they are good
But I read more about it and there's nothing actually wrong with typescript enums as long as they have a string definition, so that's cool
Fantastic! We’ve been using ts in node for a month now and it’s been lovely. This will be a fantasic addition!
Constructor parameter auto assignment is actually something I like. I guess being able to disable enum is a win, but yeah, shame about constructors. Type strippers (SWC) could handle the auto assignment, but I assume the intent is to keep Node aligned to what JS annotations will be.
but those parameter properties are very useful, because they reduce the amount of code i have to write. without those I'd need to assign each property manually in the constructor. i would also have to keep property and parameter name in sync manually, because I like consistent naming. any thoughts? or am I wrong? how can I otherwise reduce work and boilerplate if not with parameter properties? if babel supports it with plugins, so should nodejs. no excuse.
Why would node support something that isn't in the Ecma Script spec?
@@robertsandiford6223 nodejs should adopt all TS feature because there are TS devs who use them and they want to use them when they switch to vanilla nodejs also. That is a very practical down to earth argument, would you agree? What point would strictly following ecma spec have in this case? I agree that nodejs JS should follow ecma spec because its JS. But nodejs TS should follow TS spec. These are 2 different things.
@@weirdwordcombo TS has moved away from runtime features as that would create a clash between TS runtime features and new features added to JS itself. E.g. JS may one day have its own enums. We're not going to see further development of TS runtime features and support for them.
1:48 would be great if you could link to the videos or create an updated video regarding the alternatives, please :)
What is the problem with enums?
It seems they dislike that those are checked runtime. But I have the same question. Because to me it is more important write clean code with the tools a language gives me than how the language supports such a feature.
@twigsagan3857 Agree 👍
@twigsagan3857 same. And I think all of this is mostly about Node, and NOT browser. TypeScript doesn't really do anything at runtime in a browser... it's transpiled...
I guess partly it's because union types exist that can do the same thing without any extra syntax overhead, while also still having intellisense capabilities.
Sometimes enums can also be transpiled differently depending on how they're written. I can't remember exactly, but say if you wanted to get all the values of an enum type via Object.values(), it will return essentially the same values twice, but with the keys and values swapped. Something like:
{
1: "ValueA",
2: "ValueB",
"ValueA": 1,
"ValueB": 2
}
@@twigsagan3857 No, it is because it does not map to a javascript construct. The typescript compiler extra code for enum. This is an issue for type strippers like the new option in node: --experimental-strip-types
Angular developers won't use it because of class parameters extensive usage. It should be three flags instead of one and it would be all fine.
😂 skill issue, just stop using it
Yeah, since we have a DI mechanism, making things protected readonly is really nice to have
No need for constructor parameters, you can just add as a property:
class SomeComponent {
private foo = inject(Foo);
}
@@oscar1353-e7c that has some implication on when the value is being initialized in the life cycle - not entirely the same, although pretty close.
@ not exactly the same, but I can agree that it is close.
Your content is great, my friend. Thanks!
Nestjs catching strays on them @Injectable constructors from the cli tool ayy
Yeah it uses experimental decorators so no way it can use this flag
I didn't know constructor parameters are possible like that, that's pretty cool. I guess if I'm already transpiling my stuff i can make an exception for it.
Hey, will you be adding this flag to the total-typescript/tsconfig project as a default?
100%
2 questions: What's wrong with that third example? And what is meant by "erasable"?
Erasable means it can be stripped at runtime. Non-erasable typing actually affects how your code behaves, erasable typing is only visible to the developer/typescript compiler. Enums are non-erasable, as code gets generated in its place; they're a form of syntactic sugar.
@@kakschoen that was clear, thanks! I think they get stripped at compile time, though, no?
Enums do not get stripped, they get compiled into a different form.
@@mattpocockuk makes sense now, thanks! Shoulda been calling "strippable..."
Why do you recommend not using constructor property promotion?
Too implicit, and not compatible with Node/future proof
It's typescript "magic", rather than adding types to valid code.
@@mattpocockuk what does too implicit mean? why is that bad. i think it is more important that it is super intuitive. than it can be implicit, no problem. future proof? nodejs needs to support it if it wants to serve its user base.
He wants JavaScript with training wheels. Not useful additional functionality.
@ Too implicit means that it's not documented as part of MDN's classes. It's syntax that doesn't describe itself - you need to read the TypeScript docs to understand what it's doing.
If TS wants to live out its future as 'JavaScript with types', it needs to get rid of these strange hangers-on.
You should probably explain what's the problem with enums and namespace rather than just calling them weird. I still don't understand what this flag for tbh. If you opt to disable, then what's the alternative?
Ths is awesome! Do you think you'll update your tsconfig package once TS 5.8 is generally available?
Yes!
I think TS went bit overboard with the enums, including different behavior of numbers and strings that eventually resulted breaking change in TS 5.
I personally would have preferred enums to cover only auto-incrementing integers with optional redefines without backtracking and other jazz.
Disagree. Lots of what we use enums for are for DB fields and TEXT_VALUES are preferred over auto incrementing numbers because numbers can change.
To be fair, you've recommended namespaces before 😂
Type-only namespaces!
I wonder what will happen to using keyword now, they've added it not that far ago
It's a JavaScript feature, so no need to erase it
Honestly I've been using a custom Enum class for quite sime time now. Mainly because I frequently needed 2-way bindings for a specific project and enums can't be sirect class properties... (WHY)
Otro buen video, muchas gracias por alegrarme el dia!
Why didn't Node implement it though? Too hard or do they not like it?
Because:
- You need to ship source maps to make it work
- It ties Node in somewhat to TypeScript's runtime syntax, which is not a dependency they want - especially when the TS themselves are signalling that it's not the future of TS.
The link to the PR in the description needn’t and shouldn’t point to x, instead it should point to the PR directly.
It should! Fixed.
@@mattpocockuk 💙🙏
uhm what about dependency injection best practices if constructor paremeters.could be disabled?
Confused by what you mean?
@yoyo this flag doesn't disable the ability to pass things into a constructor, it just disables the shorthand syntax for creating class properties directly through the parameter list of the constructor. You can still do constructor injection just fine.
@@mattpocockuk sorry I was using my phone for the previous answer. I was wondering what would be the best syntax when using DI, if using "private readonly" as constructor params is not a best practice anymore ?
@ You can just use the normal private readonly syntax on class properties, instead of defining them in the constructor parameters.
Hmm, now we're at the point where it actually matters whether a private class property gets transpiled from `private foo` to `#foo` or not. I wish that was the case, there definitely could be at least a flag for that behaviour, but given my past lack of success suggesting such things on the typescript repo I think I'm better off just rewriting my code myself. Not sure yet what I'm going to do about methods that I need in my unit tests, but want to keep private in the production version :\
Why not just fix them?
Sure, go for it
I feel like I'm such an outlier in that I actually really like Namespaces. I don't get the hate - I find it really useful for semantic compartmentalization where names of exports get really dense and start to overlap.
given that, I'll echo other people's comments: I wish it were a little more granular, but I get how that doesn't help with the new node type stripping.
class constructor properties is really good :(
enums bad, yep
For me enums, namespaces (and modules + references) are obvious nonos from day 0, but private and protected properties seems good practice to use together with _ prefix. Or am I somewhere wrong?
Yes, private and protected properties are not going away - just the automatic assignation in the constructor.
@mattpocockuk Yeah I know but still are they really bad practice to use?
In your code, do you do this implicit assignment or assign values explicitly in the body of the constructors?
@mattpocockuk `public` vs. `Object.assign` - This is a minor thing but underlying a major tradeoff:
In my company, codebase readability is probably worth more than direct portability across the runtimes and configurations, or do you think that it is the other way?
@ I assign values explicitly.
And I don't understand why you're comparing public and Object.assign - they feel unrelated to me.
I would love it if not the constructor thing. But I don't use classes, so I guess I'm okay with it.
Great, now each and every dev can write their personal style of enums all over the code base.
I am missing some context here: why is it good that this flag is disabling these features?
Because they suck:
th-cam.com/video/jjMbPt_H3RQ/w-d-xo.html
Skill issue
@mattpocockuk Ah yeah I see! I saw the video back in the days, but I forgot about it! Yeah indeed, then it is a really good news!
Wait-does this mean that my private keyword won't work anymore? Am I not supposed to use that? I really love that though tbh...
No, it's only specifically in constructor parameters. The private keyword is erasable.
Private can be erased by tsc, it's just a "you really should not use this from outside the class", but it would not prevent you from doing it
Skill issue, don't use private, you have #
Besides the fact that JavaScript has more robust built-in support for private class members now: No, that's not what it means. This only affects constructor properties. In TS, the code
class Foo {
constructor(private bar: string) {}
}
is an equivalent shorthand for
class Foo {
private bar: string;
constructor(bar: string) {
this.bar = bar;
}
}
idk how I feel about this... I think it's more the job of a linter to enforce things like that, isn't it?
I'm so tired of TS enums and all the people I work with that keep using them for EVERYTHING. You inevitably end up with someone making MyEnum and MyEnumButBigger because you can't simply extend one enum from another, y'know something that is trivially easy if you just use a string literal union instead which is what 99% of enums usages should be. And please stop with the "but enums are easier to refactor nonsense", in >5 years working on large TS monorepos the amount of times I've had to refactor the value of an enum/string union in already deployed production code is ZERO. Also, fun fact, it STILL essentially says in the TS docs: "probably don't use TS enums unless you have a good reason to and know what you're doing".
stop saying DTOs are bad in comments. I use tsyringe as DI container. massive boilerplate incoming if i use this flag I guess. horrible. classes are used for much more than DTOs. this is a major issue if you are forced to use nodejs with native typescript support I guess. nodejs should support transpilation plugins like babel.
Good thing the flag is optional :)
enum is bad? Use it everywhere in big project
Skill issue, normal people use objects for that
@@aleksander5298 Wait till you need 2-way bindings, Aleksandrze...
@@aleksander5298 When it became skill issue, if the issue with good software is because of enums... liberal crap talking about sooner or later we are doomed, so remove enums, because u don't have anything smart to do in world, where all the same apps that are just rewritten in more baby languages...
enums considered harmful
@ Wait until you need 2-way bindings.
The "pitfalls" of enums in typescript are a non issue for the vast majority of users. I think talking about enums like they're dangerous or bad is disingenuous because they're neither. Sure it's probably good to be aware of them, but once again it will not impact the overwhelming majority of users. I've never heard you say you didn't like constructor parameter properties, but I also don't get why you wouldn't. It's similar-ish to C#'s primary constructors which isn't inherently bad either. Sure there's cases where you want to have private back fields and public facing getters, but if you're making POCOs or I guess in typescript it would be POTO or anything really that doesn't need fine grained control it's a nice way to not have to write all of the properties out, then the constructor function with it's parameters then writing the body of the constructor to do the re-assignment for all of them. Idk I probably would never use this flag, but I guess for all of you who take issue to these things good for you lol.
Javascript is the weirdest language ever made. I still don't get how this mess has become the world standard for Web.
Why everyone says that enums are odd? Why exactly? Or it is just so.e tradition not to like it?
Alfons Åberg's dad became a developer, that's crazy.
This flag is like a deprecation for the non-eraseable syntax :)
Wtf I’m no longer a wizard?
Everyone else got the normal greeting
No thanks!
So, Node, after more than a decade of existence decided will implement typescript but doesn't, so to fix it, typescript itself changes
Wouldn't it be better to, ACTUALLY implement typescript instead of just rename the extensions form "ts" to "js" and pretend everything is fine?
No, because I think everyone involved (Node and TS team) see this as a possible sea change moment to get rid of some features that they're not interested in supporting.
TS's future is as JS + Types, not as its own language with runtime features.
@mattpocockuk isn't it called JSDocs?
Don't like it. There are constructive code generations. While enums (in TS) and namespaces aren't constructive, constructor parameters are. Also wish we had type to code generation, something like
type MyType = 'foo' | 'bar';
let x: MyType;
if (element.dataset.id in MyType)
x = element.dataset.id;
Because manually writing
element.dataset.id === 'foo' || ...
Is tiresome and error prone when you extend MyType later.
This is a terrible update. I love enums and constructor property promotion and will NEVER stop using them (we use DI that depends on this). I don't get the hate towards enums, they're very useful. Namespaces I'm ambivalent about but they make more sense for a utility module over a class with static methods. I see this update as a regression.
It's opt-in
Imagine how happy you could be if you removed all the TypeScript features... and JavaScript quirks... and used a better language instead.
My dream is a dedicated TS runtime that doesn't involve JS at all.
lol! so cool
How to deal with it in nest.js?
Nothing, it's just a flag which you should keep out of your config. I don't see the TS team removing this stuff outright because of backwards compatibility, especially considering this is Microsoft and they never remove anything (see about not being able to name a file "COM")
FINALLY!
YESSSSSSSSSSSSS!!!!!!!!
Nom! Nom! Nom! Very tasty! 🏁🏁🏁🏁🏁🏁🏁 😃
Enums are the worst feature of the language by far. Alternatives are always better.
Finally