build_pubspec 0.2.0+1 build_pubspec: ^0.2.0+1 copied to clipboard
Extract pubspec details (such as package version, author and description) into Dart code.
build_pubspec
#
This package helps you convert fields from your pubspec.yaml
file into Dart code.
Based on the fields in your pubspec, this package will generate Dart code so
that you can access these fields easily from your Flutter, AngularDart, command-line tool, or backend app.
Common use-cases #
- Create command-line apps and fill out the
help
headline andversion
commands automatically - Create beautiful example apps for your Flutter packages and plugins with an always-up-to-date description and links to your docs, issue tracker and repository
- Display the current version of your app to your users in your mobile app
- Add app version to your logs, analytics or backend calls
Usage #
-
Add
build_pubspec
to yourpubspec.yaml
asdev_dependency
. Make surebuild_runner
is also listed as development dependency.dev_dependencies: build_runner: ^1.0.0 build_pubspec: ^1.0.0
-
Get dependencies:
pub get
. If you are using Flutter, runflutter pub get
. -
Build!
$ pub run build_runner build
Based on the following
pubspec.yaml
file...name: build_pubspec_example description: This is an example description. publish_to: 'none' authors: - Vince Varga <vince.varga@dartside.dev> version: 0.1.2
... the default build will create the
lib/src/pubspec.dart
file:// Generated file. Do not modify. // // This file is generated using the build_pubspec package. // For more information, go to: https://pub.dev/packages/build_pubspec const List<String> authors = [ 'Vince Varga <vince.varga@dartside.dev>', ]; const String description = '''This is an example description.'''; const String name = '''build_pubspec_example'''; const String version = '''0.1.2''';
-
Use the generated Dart code.
You can now include this Dart file in your app code if you want to reference a field from your
pubspec.yaml
file.
Examples #
I maintain various examples for this package. Check them all out in the examples/
folder.
Customize your build #
Create a build.yaml
file in your project.
Change field names #
You can customize the output Dart file's fields names, for example, if you want to output the version
as const String v = '...';'
.
If a key is not present in the pubspec.yaml
, it will not be part of the output Dart file.
If you wish to skip a key, set its field name option to empty string.
targets:
$default:
builders:
build_pubspec:
options:
authors_field_name: betterAuthors
description_field_name: betterDescription
documentation_field_name: betterDocumentation
homepage_field_name: betterHomepage
issue_tracker_field_name: betterIssueTracker
# name field is intentionally left empty in this example to
# demo how to skip the name in the output dart file.
name_field_name: ''
repository_field_name: betterRepository
version_field_name: betterVersion
Change output file #
By default, the destination file is lib/src/pubspec.dart
.
If you wish to change it, create a build.yaml
file in your project:
targets:
$default:
builders:
build_pubspec:
options:
destination_file: 'lib/details.dart'
Part files with source_gen
#
It is also possible to generate the version string as a part of an existing library in your package.
Disable the default builder, and enable the part builder:
targets:
$default:
builders:
build_pubspec:
enabled: false
build_pubspec|build_pubspec_part:
enabled: true
generate_for: ['lib/src/example.dart']
options:
version_field_name: 'exampleVersion' # defaults to 'packageVersion'
Make sure your lib/src/example.dart
contains part 'example.version.g.dart';
,
Once you run pub run build_runner build
, the part file will be generated into lib/src/my_lib.version.g.dart
.
Acknowledgements #
This package is based on build_version
. Thank you for the original author, Kevin Moore. It also includes fixes to the original repository from Alexey Knyazev. I could not have created this package without their original work.
TODOs #
I just got rid of Travis, so I need to take care of a new CI/CD pipeline. GitHub Actions.
- analyze, lint, run tests, all the usual stuff
- go to example folders and make sure the examples run correctly, make sure no git changes