When it comes to TypeScript’s private property declarations, users still have to be careful not to trample over properties declared in superclasses. When using ECMAScript # private fields, no subclass ever has to worry about collisions in field naming.
If you’re a library author, removing or renaming a private field should never cause a breaking change.Īs we mentioned, another benefit is that subclassing can be easier with ECMAScript’s # privates because they really are private. This hard privacy is really useful for strictly ensuring that nobody can take use of any of your internals. TypeScript 3.8 brings support for ECMAScript’s private fields, part of the stage-3 class fields proposal. This might be useful if you want to ensure no values are being accidentally imported, but still make side-effect imports explicit.įor more information about the feature, you can take a look at the pull request, and relevant changes around broadening where imports from an import type declaration can be used. error: this preserves all imports (the same as the preserve option), but will error when a value import is only used as a type.This can cause imports/side-effects to be preserved. preserve: this preserves all imports whose values are never used.It’s going to continue to be the default, and is a non-breaking change. remove: this is today’s behavior of dropping these imports.In conjunction with import type, TypeScript 3.8 also adds a new compiler flag to control what happens with imports that won’t be utilized at runtime: importsNotUsedAsValues. error! A type-only import can specify a default import or named bindings, but not both.
0 kommentar(er)
