搜索插件、代码仓与 APP 分类

GitHub 代码仓cmc5788/global_assert

global_assert

一个用于在构建时断言的 Dart 微库。

global_assert 项目封面
星标
17
复刻
0
最近推送(UTC)
2021年12月21日
项目状态
未归档

原始 README

以下为英文项目原文快照,最新内容请访问 GitHub。

A micro-library for asserting at build time.

pub package Build Status Coverage

It's a common practice to configure a Dart app using const (build-time) values. There are benefits to this approach, such as enabling tree shaking of unused code.

This library makes it easy to do build-time assertions about such constants so that misconfigured apps fail at build-time instead of failing at runtime.

Usage

Use this library to validate your app's const values at build time. Anything can be annotated with @Assert.

//
// This app will fail compilation with '--define=MY_VAL=foo'
//

@Assert(
  myBuildTimeVal == 'val1' || myBuildTimeVal == 'val2',
  'myBuildTimeVal must be one of "val1" or "val2"',
)
const myBuildTimeVal = String.fromEnvironment('MY_VAL');

void main() {
  print('myBuildTimeVal is "$myBuildTimeVal"');
}

FAQ

🤔 How does this even work?!

The Dart compiler invokes annotation constructors at compile-time. This micro-library takes advantage of that to "trick" the compiler into allowing build-time asserts that can be placed (almost) anywhere. Special thanks to Kyle Turney for the inspiration behind this approach.

Why not allow an assert without a message?

Unfortunately, Dart doesn't treat an assert with a null message the same as an assert without any message at all. This means that we would need two constructors for @Assert to enable both messageless asserts and asserts with messages. Instead, we made the design choice when creating this micro-library that @Assert should require a non-null message. This enforces more meaningful compilation failure messages.

Will this always be needed?

We expect that when Dart supports metaprogramming, this library will be deprecated.

Christopher Casey GitHub avatar
GitHub 作者

Christopher Casey ↗

<3 mobile, lots of Rx, Flutter, Android, iOS

@toyota-connected Dallas, Texas官方网站 ↗
语言Dart

此仓库发布的插件

使用的依赖

依赖清单 3 项

  • lints开发依赖^1.0.0
  • path开发依赖^1.8.1
  • test开发依赖^1.16.0

如何选择适合项目的代码仓?

先按使用场景筛选,再比较项目活跃情况,最后到原始仓库核对使用要求。

  1. 通过仓库名、作者或描述搜索,再按技术分类缩小范围。
  2. 结合星标、复刻与最近推送比较项目;星标反映社区关注,不代表质量保证。
  3. 使用前在 GitHub 核对 README、许可证与 Issues。

来源与维护

“A repository is the most basic element of GitHub.”

GitHub Docs — About repositories ↗