Dart version 2.14 is now available

supports Apple Silicon, adds default lint, better tools and new language features to improve productivity.

This month, we released the official version of Dart SDK 2.14. The new version aims to create the best platform for building applications through a unique combination of portability, productivity, and robustness. This time, we provide better support for Apple Silicon and provide many productivity-enhancing features, such as standard lint code rules for catching errors when you write code through code style analysis, faster publishing tools, and more Good cascading code format and some minor language feature updates.

Since Apple released the new Apple chip processor chip at the end of 2020, we have been working to update the Dart SDK to increase native operation support on the new processor. The required update has been provided in the dev channel for some time. In the past month, the beta channel has also provided support. Starting from Dart 2.14.1, it can be used in the Dart stable channel. When you download when a macOS the SDK, make sure to choose ARM64 option. Please note that the Dart SDK bundled with the Flutter SDK does not yet support these improvements.

The support includes running SDK and Dart virtual machine on Apple chip, and also supports executable files compiled and run on Apple chip (using dart compile command). Since Dart command line tools use native Apple chip support, they start much faster.

Developers usually prefer to make the code follow a certain style. Many of these rules are not just style preferences (such as the well-known discussion of tabs and spaces), but also cover coding styles that may cause errors or introduce errors. For example, the Dart style guide requires curly braces for all control flow structures, such as if-else statements. This prevents the classic "dangling else" problem, which is ambiguity when there are multiple nested if-else statements. Another example is the type of inference, although the variable has an initial value in the declaration, the use of type inference is no problem, but in variable declaration uninitialized manually specify the type when it is very important that you make sure that the type of security.

Of course, you can also choose a form of manual review to maintain a good code style, which is the familiar code review. However, it is usually more effective to run static analysis to enforce the rules while writing the code.

In Dart, this static analysis is which is highly configurable by . We have hundreds of style rules (also called lints). With such a wealth of options, we may not know which rule to enable. The Dart team maintains a Dart style guide , which describes what we believe is the best practice for writing and designing Dart code. Before this we have not provided a formal official style guide for linter rules.

Many developers, including the score engine on the pub.dev website, are using a lint rule pedantic However, pedantic originated from Google's internal Dart style guide. For historical reasons, it is not the same as the general Dart style guide. Therefore, the Flutter framework has never used the pedantic rule set, but has its own set of normative rules.

This may sound a bit messy, but it is true. But in this release, we are happy to announce that we now have a new set of lint sets to implement style guides, and the Dart and Flutter SDK have been updated to use these rule sets for new projects by default. These rule sets include:

• package:lints/core.yaml : The main rule in the Dart style guide. We believe that all Dart code should follow this rule. The pub.dev scoring engine has been updated to replace pedantic with these rules.
• package:lints/recommended.yaml : core rules, plus additional recommended rules. This set of rules is recommended for all general Dart code.
• package:flutter_lints/flutter.yaml : Core and recommended rules, plus additional Flutter-specific recommended rules. This set of rules is recommended for all Flutter code.

If you use pedantic in your existing project, we strongly recommend that you upgrade to these new rule sets. Upgrading from pedantic to only takes a few steps .

We have made some optimizations to the way the Dart formatter formats cascaded In the past, formatters would produce messy formatting in some cases. For example, in this example, how is doIt()

var result = errorState ? foo : bad..doIt();

It seems that it will always be bad , but in fact the cascade applies to the entire? Expression, so the cascade is called on the result of the expression, not just on the false clause. The new formatter will Make this clear:

var result = errorState ? foo : bad
 ..doIt();

Other changes involve how to format lines with multiple cascades, and how far the cascades are generally indented. We have also greatly improved the formatting speed of the code containing cascades; in protocol buffer , we have seen the formatting speed <highlight>increased by 10 times</highlight>.

For all the details about the issue, please refer to and track this Pull Request .

Currently, when you publish a package to pub.dev when communities warehouse, pub will capture all the files in the folder, but will skip the hidden files (those with point . beginning of the file) and .gitignore in Files listed. Some developers need to be able to control which files are ignored outside the .gitignore For example, you may tool/ folder that you use to maintain your package, but these tools have nothing to do with the people who use your package.

pub command in Dart 2.14 supports the new .pubignore file, in which you can list the files you don't want to upload to pub.dev. This file uses the same format as the .gitignore For more information, please refer to the package release document .

Although pub may be most commonly used to manage code dependencies, it also has a second important purpose: to provide powerful tool support. One example is the Dart test tool, which is used through the dart test command. This command is actually just a package of the pub run test:test command, which runs the test entry in package:test Before calling this entry, pub first compiles it into native code that can run faster.

Before Dart 2.14, pubspec (including those package:test ) will invalidate this test build, and you will see a bunch of output like this, which contains a "pre-compiled executable":

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

In Dart 2.14, pub becomes smarter about when to cancel the build step, so it will only build when the version changes. In addition, we improved the way we use parallelization to execute the build step, so the step itself will complete faster. On some packages we tested, we saw that it only took half the time.

Dart 2.14 also includes some small language features. This time, we will focus on more specific improvements. These improvements may only be small features, but they can achieve more professional use cases that were not previously supported.

First, we added a new triple shift operator ( >>> ). This is similar to the existing shift operator ( >> ), but >> performs arithmetic shift, >>> performs logical or unsigned shift, where the zero bit will be shifted into the most significant number regardless of whether the shifted number is positive or negative Bit.

We also removed the old restriction on type parameters, which did not allow the use of generic function types as type parameters. All the following were invalid 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;

Finally, we made a small adjustment to the annotation type ( are usually used to capture metadata in Dart code). Previously, annotations could not pass type parameters, so @TypeHelper<int>(42, "The meaning") are not allowed. This restriction has now been removed.

We have made many enhancements to the core Dart package and code base, including:

• dart:core : Added static methods hash , hashAll and hashAllUnordered to the Object class. These can be used to combine the hash codes of multiple objects in a consistent manner ( hashAll example );
• dart:core : The native DateTime class can now better handle local time, instead of daylight saving time changes that are accurate to one hour-for example, Lord Howe Island in Australia, which has a 30-minute time difference;
• package:ffi : Added support for using the arena allocator to manage memory ( example ). Arenas is a form of based on region memory management , once exiting arena/region, resources will be automatically released;
• package:ffigen : now supports generating Dart type definitions from C type definitions.

Dart 2.14 also includes some smaller, has announced in advance through the destructive update (breaking changes). It is expected that these changes will only affect some special use cases. These disruptive updates are as follows:

#46545 : Remove support for ECMAScript5

All modern browsers already support the latest ECMAScript version, so two years ago we announced , which no longer supports ECMAScript 5 (ES5). This allows us to take advantage of the latest ECMAScript improvements and generate smaller output. In Dart 2.14, this work has been completed and the Dart Web compiler no longer supports ES5. Therefore, older browsers (such as IE11) will no longer support it.

#46100 : Deprecated stagehand, dartfmt and dart2native

Dart 2.10 blog post in October 2020, we announced the work of combining all Dart CLI developer tools into a single group dart command tool (similar to flutter command tool). As part of this evolution, Dart 2.14 deprecated the previous dartfmt and dart2native commands, and discontinued stagehand . These tools have equivalent replacements unified dart command tool

#45451 : Deprecated VM native extension

We have deprecated the native extension of Dart VM, which is our old mechanism for calling native code from Dart code. DART FFI (external features interface) is an example of the use of this mechanism for our current, we are actively development it to make it more powerful features and easy to use.

We launched a sound air security in the Dart 2.12 Null safety is the latest major productivity feature of Dart, designed to help you avoid null value errors, a type of error that is usually difficult to find.

Since our last update, we have seen tremendous progress in the migration of existing packages and applications in order to achieve the advantage of air safety sanity check. For the packages on pub.dev, 100% of the top 250 packages already support null security, and 94% of the top 1000 packages support it. This means that more developers can run their applications sound and empty security Analysis shows that 56% of flutter run commands are executed in a completely sound manner. Thanks to all the developers in the ecosystem, thank you for your migration work!

The enhanced Dart SDK with the above changes is already available in Dart 2.14.1 and Flutter 2.5 SDK. We hope you will enjoy these new improvements and features.

Thanks to the Dart community

In addition, we would like to take this opportunity to express our gratitude to the Dart community. Through some recent updates to the programming language survey, we can see that Dart is gaining momentum. The well-respected RedMonk ranked in the 1615d113c9fbc3 mentioned "Dart's significant rise", and Dart was included in the top 20 for the first time. StackOverflow's 2021 comprehensive developer survey also gratifying. According to reports, Dart is the seventh most popular programming language for developers. We are really happy to see the continued growth and development momentum of the Dart platform.

Thanks to flutter.cn community members (@AlexV525, @Vadaski, @MeandNi) and Lynn for reviewing and contributing to this article.