Support for Apple Silicon, added default Lint, better tools, and new language features to improve productivity.

This month, we released the official Dart SDK 2.14, which aims to build the best platform for building applications with a unique combination of portability, productivity, and robustness. This time around, we’ve provided better support for Apple Silicon and a number of productivity enhancements, such as standard Lint code rules for catching bugs as you write code through code style analysis, faster publishing tools, better cascading code formats, and some minor language feature updates.

Since Apple released its new Apple chip processor chip in late 2020, we have been working on updating the Dart SDK to add native runtime support on new processors. The required updates have been available in the Dev channel for some time, and beta channel support has been available in the past month, starting with Dart 2.14.1, in the Dart Stable channel. When you download an SDK for macOS, be sure to select the ARM64 option. Please note that the Dart SDK bundled with the Flutter SDK does not yet support these improvements.

This support includes running the SDK and Dart virtual machines on Apple chips, as well as compiling executable files on Apple chips (using the Dart compile command). Because the Dart command line tools use native Apple chip support, they start up much faster.

Developers often prefer to have their code follow a certain style. Many of these rules are not just stylistic preferences (such as the well-known TAB versus space discussion), but also cover coding styles that can cause 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, where there is ambiguity when there are multiple nested if-else statements. Another example is type inference. While it is fine to use type inference when declaring variables with initial values, it is important to manually specify the type when declaring uninitialized variables to ensure type safety.

Maintain good code style, of course, you can also choose some form of manual review, also known as code review. However, it is often more effective to run static analysis while writing code to enforce rules.

In Dart, this static analysis is highly configurable, and we have hundreds of style rules (also known as LINTs). With such a wealth of options, it can be confusing to choose which rules to enable. The Dart team maintains a Dart Style guide that describes what we believe are best practices for writing and designing Dart code, and until now we have not provided a formal linter rule for the official style guide.

Many developers, including pub.dev’s scoring engine, use a lint rule called Pedantic. However, Pedantic originated in Google’s internal Dart Style guide, which for historical reasons is not the same as the general Dart style Guide. Thus, the Flutter framework never uses a Pedantic set of rules, but has its own set of normative rules.

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

  • Package: LINts /core.yaml: The main rule in the Dart Style guide that we believe all Dart code should follow. The pub.dev scoring engine has been updated to use these rules instead of Pedantic.
  • Package: lints/it. Yaml: core rules, with additional recommendations. This rule is recommended for all generic Dart code.
  • Package: Flutter_lints /flutter. Yaml: Core and recommendation rules, plus additional flutter specific recommendation rules. This rule is recommended for all Flutter code.

If you use Pedantic in your existing projects, we strongly recommend that you upgrade to these new rule sets. Upgrading from Pedantic is just a few steps away.

We made some optimizations to the way the Dart formatter formats the cascading code. Previously, formatters produced messy formatting in some cases. For example, how is doIt() called in this example?

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

It looks like it’s always called by bad, but it actually applies to the whole thing, right? Expression, so the cascade is called on the result of that expression, not just on the false clause. The new formatter makes this clear:

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

Other changes relate to how lines with multiple cascades are formatted, and how far cascades are generally indented. We have also greatly improved the formatting speed of code that contains cascades; In the Dart code generated for the protocol buffer, we see a 10-fold increase in formatting speed.

See and trace the Pull Request for all the details on this issue.

Currently, when you publish a package to pub.dev community repository, Pub captures all files in that folder, but skips hidden files (those that start with a dot. The files listed in.gitignore. Some developers need to be able to control which files are ignored outside the.gitignore list. For example, you might have internal development tools in a tool/ folder that you use to maintain your package, but those tools have nothing to do with the people who use your package.

The updated pub command in Dart 2.14 supports the new.pubignore file, where you can list files you don’t want uploaded to pub.dev. This file uses the same format as the.gitignore file. See the Package release documentation for more information.

While PUB is probably most commonly used to manage code dependencies, it also has a second important use: it provides powerful tool support. One example is the Dart test tool, used with the Dart test command. This command is really just a wrapper around 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.

Prior to Dart 2.14, any change to PubSpec (including changes unrelated to Package: Test) invalidates this test build, and you’ll 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 becomes smarter about when to cancel the build step, so it only builds when the version changes. In addition, we have improved the way we use parallelization to perform the build step, so that the step itself completes faster. On some of the packages we tested, we saw it in half the time.

Dart 2.14 also includes some minor language features. This time, we focused on more specific improvements that might be small features but enable more specialized use cases that weren’t previously supported.

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

We also removed the old restriction on type parameters, which did not allow the use of generic function types as type parameters. 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, we made a small change to the annotation type (annotations like @deprecated are commonly used to capture metadata in Dart code). Previously annotations could not pass type parameters, so codes like @TypeHelper

(42, “The meaning”) were not allowed. That restriction has now been removed.

We have made a number of enhancements to the core Dart package and codebase, including:

  • dart:core: adds static methods to the Object classhash 、hashAll 和 hashAllUnordered. These can be used to combine hash codes for multiple objects in a consistent manner (HashAll sample);
  • dart:core: The native DateTime class can now handle local time better than changes to daylight saving time that are accurate to one hour — such as Lord Howe Island in Australia, which has a 30 minute time difference offset;
  • 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 when exiting an arena/region;
  • Package: FFigen: Dart type definition generation from C type definition is now supported.

Dart 2.14 also contains some smaller, pre-announced breaking changes. These changes are expected to affect only a few specific use cases, and these disruptive updates are as follows:

# 46545: Cancel support for ECMAScript5

All modern browsers already support the latest version of ECMAScript, so two years ago we announced a plan to no longer support ECMAScript 5 (ES5). This allows us to take advantage of the latest ECMAScript improvements to produce smaller output. In Dart 2.14, this work is done and ES5 is no longer supported by the Dart Web compiler, so older browsers such as IE11 are no longer supported.

# 46100: Deprecated Stagehand, DarTFMT, and Dart2native

In Dart 2.10 blog post in October 2020, we announced the work of combining all Dart CLI developer tools into a single group of Dart command tools (similar to the FLUTTER command tools). As part of this evolution, Dart 2.14 deprecated the previous DartfMT and Dart 2native commands and discontinued Stagehand. These tools have equivalent alternatives in the unified DART command tool.

# 45451: Deprecate VM native extensions

We have deprecated the native extension to the Dart VM, which was the old mechanism we used to call native code from Dart code. Dart FFI (External Functional Interface) is our current mechanism for this use case, and we are actively developing it to make it more powerful and easy to use.

We introduced robust air safety in Dart 2.12 in March. Empty safety is the latest major productivity feature in Dart and is designed to help you avoid null errors, a class of errors that are often hard to spot.

Since our last update, we have seen great progress in migrating existing packages and applications to achieve the health check benefits of air security. For packages on pub.dev, 100% of the top 250 packages already support space security, and 94% of the top 1000 packages do. This means that more developers can run their applications with fully sound empty security. Analysis showed that 56% of flutter run commands were executed in a completely sound manner. Thank you to all the developers in the ecosystem for your migration work!

The enhanced Dart SDK that includes the above changes is available for Dart 2.14.1 and the Flutter 2.5 SDK. We hope you enjoy these new improvements and features.

Thanks to the Dart community

Also, we would like to take this opportunity to thank the Dart community. With some recent updates to the programming language survey, Dart is gaining momentum. The respected RedMonk rankings cited a “significant rise in Dart” and included it in the top 20 for the first time. StackOverflow’s developer Roundup 2021 is also exciting. Dart is reported to be the seventh most popular programming language among developers. We’re really excited to see continued growth and momentum in the Dart platform.

Thanks to the members of the flutter.cn community (@alexv525, @Vadaski, @Meandni) and Lynn for their contribution to this article.