Original link: medium.com/dartlang/an…

The release of Dart 2.14 provides better support for Apple Silicon processors and adds more productivity features, such as catching lint errors through code style analysis, faster publishing tools, better cascading code formats, and minor language feature updates.

The Dart SDK supports Apple Silicon

Since Apple released its new Apple Silicon processor in late 2020, the Dart SDK has been working to add Native execution support on that processor.

Dart 2.14.1 now officially adds support for Apple Silicon. When downloading the Dart SDK for MacOS, be sure to select the ARM64 option. The Dart SDK in the Flutter SDK does not yet bind this improvement.

This update supports running the SDK/Dart VM itself on Apple Silicon, as well as running executable files after Dart Compile on Apple Silicon. Because the Dart command line tools use native Apple Silicon, they start up much faster.

Dart shares standard Lint with Flutter

Developers often need their code to follow a certain style, and many of these rules go beyond style preferences (such as the well-known problem of tabs and Spaces) to cover coding styles that can cause or introduce errors.

For example, the Dart style guide requires curly braces for all control flow constructs, such as if-else statements. This prevents classic dangling else problems, where multiple nested if-else statements can cause interpretation ambiguity.

Another example is type inference. While it is fine to use type inference when declaring variables with initial values, it is important to specify the type when declaring uninitialized variables because it ensures type safety.

Good code style is usually maintained through code reviews, but it is often much more effective to enforce rules by running static analysis as code is written.

This static analysis rule is highly configurable in Dart, which provides hundreds of style rules (also known as LINTs), and with such a wealth of options, choosing to enable these rules can be a bit overwhelming at first.

Dart. Dev /guides/lang…

Lint rule: dart.dev/tools/linte…

The Dart team maintains a Dart Style guide that describes what the Dart team believes is the best way to write and design Dart code.

Dart. Dev /guides/lang…

Many developers, as well as the pub.dev site scoring engine, use a set of lint rules called Pedantic. Pedantic is derived from Google’s internal Dart style guide, which for historical reasons differs from the general Dart style guide. In addition, the Flutter framework never uses Pedantic’s rule set, but has its own set of normative rules.

This may sound confusing, but in this 2.14 release, the Dart team is pleased to announce that there is now a whole new lint set to implement the code style guide, and Dart and the Flutter SDK use these rule sets for new projects by default:

  • Package: Lints /core.yaml: The main rule in the Dart Style Guide that all Dart code should follow, the Pub. dev scoring engine has been updated to lints/core instead of Pedantic.

  • Package: lints/it. Yaml: core rules and recommended rules, which they will apply to all general advice Dart code.

  • Package: Flutter_lints /flutter. Yaml: A set of flutter specific recommendation rules beyond the core and recommendation. This set is recommended for all flutter code.

If you already have an existing Dart or Flutter project, upgrading to these new rulesets is highly recommended. Upgrading from Pedantic is only a few steps away: github.com/dart-lang/l… .

Dart formatter and cascade

Dart 2.14 has some optimizations for how the Dart formatter uses the cascading formatting code.

Formatters have been confusing in some cases before, for example what does doIt() call in this example?

varresult = errorState ? foo : bad.. doIt();Copy the code

It looks like it’s called by bad, but it’s used for the whole thing, right? On an expression, so the cascade is called on the result of that expression, not just on the false clause, which the new formatter clearly describes:

 varresult = errorState ? foo : bad\ .. doIt();Copy the code

The Dart team also made it much faster to format code that contains cascades; In the Dart code generated by the protocol buffer, you can see a 10-fold increase in formatting speed.

Pub supports ignoring files

Currently, when a developer publishes a package to the pub.dev community, pub grabs all files in that folder, but skips hidden files (to.. Leading file) and.gitignore file.

The updated pub command in Dart 2.14 supports the new.pubignore file, where developers can list files they don’t want uploaded to pub.dev using the same format as the.gitignore file.

For more information, see the package distribution documentation dart.dev/tools/pub/p…

Pub and dart test performance

Although PUB is most commonly used to manage code dependencies, it has a second important use: driving tools.

For example, the Dart test tool runs with the Dart test command, which is really just a wrapper around the command pub run test:test, package:test before calling the test entry point, Pub first compiles it into native code that can run faster.

Any changes to PubSpec prior to Dart 2.14 (including changes unrelated to Package: Test) will invalidate this test build, and you’ll also see a bunch of output like this containing “precompiled executables” :

$ dart test\
Precompiling executable... (11.6s)\
Precompiled test:test.\
00:01 +1: All tests passed!
Copy the code

In Dart 2.14, PUB is smarter about build steps, making builds happen only when version changes, and also improves the way build steps are performed using parallelism so they can be done faster.

New language features

Dart 2.14 also includes some language feature changes.

First, a new triple shift operator (>>>) was added, which is similar to the existing shift operator (>>), but >> performs an arithmetic shift and >>> performs a logical or unsigned shift in which the zero bit is moved to the most significant bit regardless of whether the digit being shifted is positive or negative.

The old restriction on type parameters, which did not allow generic function types to be used as type parameters, is also removed. All of the following were not valid before 2.14, but are now allowed:

late List<T Function<T>(T)> idFunctions;
var callback = [<T>(T value) => value];
late S Function<S extends T Function<T>(T)>(S) f;
Copy the code

Finally, minor changes were made to annotation types (such as @deprecated annotations commonly used to capture metadata in Dart code). Previously annotations could not pass type parameters, so @TypeHelper

(42, “The meaning”) was not allowed to use code like this. That restriction has now been lifted.

Package and core library changes

A number of enhancements have been made to the core Dart package and library, including:

  • Dart: Core: Adds static methods hash, hashAll, and hashAllUnordered.

  • The Dart: Core: DateTime class now handles local time better.

  • Package: FFI: Added support for memory management using the Arena allocator (example). Arenas is a region-based form of memory management that automatically frees resources once you exit arena/region.

  • Package: FFigen: Dart type definition generation from C type definition is now supported.

A major change

Dart 2.14 also contains significant changes that are expected to affect only a few specific use cases.

# 46545: Cancel support for ECMAScript5

All browsers support the latest version of ECMAScript, so TWO years ago Dart announced plans to deprecate support for ECMAScript 5 (ES5), which allows Dart to take advantage of improvements in the latest ECMAScript and produce smaller output. In Dart 2.14, this work is complete and ES5 is no longer supported by the Dart Web compiler. Older browsers (such as IE11) are therefore no longer supported.

# 46100: Deprecated Stagehand, DarTFMT, and Dart2native

In an October 2020 Dart 2.10 blog post announcing the combination of all Dart CLI developer tools into a single combined Dart tool (similar to the Flutter tool), Dart 2.14 deprecates the Dartfmt and Dart 2native commands and stops using Stagehand, both of which have equivalent alternatives in Dart tool.

# 45451: Deprecate the VM Native extension

The Dart SDK has deprecated the Dart VM Native extension, which is an older mechanism for calling Native code from Dart code, and the Dart FFI (Foreign Function Interface) is a new mechanism currently being developed for this use case to make it more powerful and easy to use.