Repository navigation
Update package documentation - #605
Conversation
sethladd
left a comment
There was a problem hiding this comment.
overall comment: I think we need to work on the taxonomy and its usefulness to our users. I think we can simplify the taxonomy.
|
|
||
| ## Package introduction | ||
|
|
||
| Dart packages enable the creation of modular code that can easily be shared. A |
There was a problem hiding this comment.
Should we just say "Packages ..." instead of "Dart packages" ?
There was a problem hiding this comment.
I would keep "Dart packages" here.
There was a problem hiding this comment.
Yes, I will keep it. There are also java, swift, etc. packages that a plugin developer will be familiar with.
| [AngularDart](https://webdev.dartlang.org/angular) and Flutter. A concrete | ||
| example is the [`path`](https://pub.dartlang.org/packages/path) package. | ||
|
|
||
| * *Flutter packages*: General packages which contain Flutter specific |
There was a problem hiding this comment.
I'm not sure we want to make this distinction. The kind of package is the same: a pub package.
I think the user cares about one thing:
- where do I go to see all the packages I can use as a Flutter developer
The differences you talk about here are implementation details that probably don't matter. Only: "will it work with Flutter?"
There was a problem hiding this comment.
See above, agree consumers don't care. Producers need to care (and this is in developing-packages.md)
| their use to Flutter only. A concrete example is the | ||
| [`fluro`](https://pub.dartlang.org/packages/fluro) package. | ||
|
|
||
| * *Flutter plugins*: Flutter packages which in additional to the Dart code also |
There was a problem hiding this comment.
I think the package/plugin distinction probably isn't too helpful. A plugin isn't a sub-type of package.
maybe some packages offer plugins, but it's still a package.
|
|
||
| ### Package types {#types} | ||
|
|
||
| Flutter supports several kinds of packages: |
There was a problem hiding this comment.
Maybe the framing is better as : "there are two kinds of code you can put into a Flutter package: dart code, and native code. If you are writing Dart code that has a dependency on Flutter, do this: ...."
(instead of "different kinds of packages", let's use "packages can contain different kinds of code")
There was a problem hiding this comment.
I totally agree for package consumers. But you re commenting on 'developing-packages.md'; I don't see how we can avoid knowledge of the differences for producers.
Look at 'using-packages.md', I just talk about packages there.
There was a problem hiding this comment.
Whoops, sorry this was meant as a reply to your "overall taxanomy" comment up top
There was a problem hiding this comment.
as a package developer, it's still one kind of package. It can contain a few different things: dart library, native code, examples, LICENSE, etc. But it's one package format.
The details you talk about are important, I'm commenting on the phrasing. s/types of packages/kinds of things inside a package
There was a problem hiding this comment.
Please don't call it "native" code. There's nothing more native about Java than Dart on Android, they both compile down to machine code, and neither are what the kernel is written in.
There was a problem hiding this comment.
Landed on a compromise: There are Dart packages and Plugin packages. We do need this distinction for authors as the steps for developing one are very different. We do not need the distinction for consumers as the API of both types (and all packages in general) is Dart.
|
|
||
| ## Developing packages | ||
|
|
||
| ### Create a package project |
There was a problem hiding this comment.
You use "-ing" in many titles, but you use "Create" here. Maybe "Creating..." is more consistent
There was a problem hiding this comment.
also, do we mean "project" ? I think that's superfluous. "Creating a package" works.
| * From the terminal: Run `flutter packages get` | ||
| * From IntelliJ: Click 'Packages Get' in the action ribbon at the top of `pubspec.yaml` | ||
|
|
||
| 1. Build or run your app. As part of this, Flutter will add the package code to |
There was a problem hiding this comment.
This is a little confusing. The code was already added to my add when I installed ("get") the package.
I'm not sure we need this last bullet. Only two steps! :)
maybe, Step Three is "import the package's library into your app"
| in IntelliJ). This will retrive the highest available version of the package, | ||
| which is allowed by the version constraint you have specified in `pubspec.yaml`. | ||
|
|
||
| ### Dependencies on unpublished packages |
There was a problem hiding this comment.
This seems generic and duplicates existing docs. Should we just link to somewhere?
There was a problem hiding this comment.
I couldn't find a short set of existing docs for this, so given the important of understanding decided a bit of duplication was OK. I do link to the Pub versioning guide for complete details.
|
|
||
| ## Examples | ||
|
|
||
| ### Example: Using the CSS Colors package {#css-example} |
There was a problem hiding this comment.
You say "CSS Colors package" and then you start talking about URL Launcher. Is that intentional?
There was a problem hiding this comment.
Oh, my bad, left over from an older version of this
|
|
||
| 1. Run `flutter packages get` in the terminal, or click 'Packages get' in IntelliJ | ||
|
|
||
| 1. Open `lib/main.dart` and replace its full contents with: |
| The [URL Launcher](https://pub.dartlang.org/packages/url_launcher) plugin | ||
| enables you to open the default browser on the mobile platform to display a | ||
| given URL. It demonstrates how packages may also contain platform-specific code | ||
| (we call these packages 'plugins'). It is supported on both Android and iOS. |
There was a problem hiding this comment.
It doesn't seem like there's any difference between installing and using a package, or a package+plugin.
If there is no difference, do we need this example?
There was a problem hiding this comment.
I think this helps deliver that very message; if you are a consumer there is no difference.
|
Thank you very much for working on this!! |
|
Thanks for all the great feedback! Uploaded a v2, please take a look. |
|
|
||
| ### Package types {#types} | ||
|
|
||
| Flutter supports several kinds of packages: |
There was a problem hiding this comment.
I think we're being confusing here. There is one type of package: a pub package (or, call it a Dart package). It can contain many different kinds of things: Dart code, plugin code, or a combination.
I agree that package developers might want to know the different kinds of things they can put in it.
If you're willing to change this phrasing to something like:
- Flutter uses pub for its package format and distribution.
- A pub (Dart) package can contain many things: Dart code, plugin code, example code, assets, and more.
Maybe it's as simple as "Dart packages can contain several kinds of code: Dart, plugin"
So, it's not about supporting different kinds of packages, it's that there are different kinds of contents.
There was a problem hiding this comment.
I don't see the confusion; actually, I find what you are suggesting more confusing, and over-abstracted.
To use an analogy, the term "xml file" is commonly used rather than the more generic "text file containing text in xml format". It's just convenient to use more concrete terms.
| To test the package, add [unit tests](https://flutter.io/testing/#unit-testing) | ||
| in a `test` directory. | ||
|
|
||
| ## Developing plugin packages {#plugin} |
There was a problem hiding this comment.
Then this would become "Developing packages with plugins"
sethladd
left a comment
There was a problem hiding this comment.
LGTM but I think we have a much clearer definitions if we talk about a single type of package: Dart/pub, and the various contents/components inside the package.
Putting a plugin into a package doesn't change the type of the package. It's still a pub package.
|
Yes, a plugin package is still a Dart package; in fact, it's a specialization of a Dart package. Made that clearer. |
|
TravisCI failures: These are the auto-inserted links for the 'Edit Source' action -- those fail, as these new pages are not on GitHub yet, as the PR hasn't merged yet. Will have to update the Rakefile to skip these. |
Skip links that have been auto-inserted for the 'Edit Source' action
Add wildcard
Fix RegExp
Fixes flutter/flutter#10070