Next steps with this project

[WieFel]

So I would suggest that we take the following next steps:

1. Edit the readme: creadit the previous authors of tinycolor package and adapt other stuff where needed
2. Set up organization on pub.dev and publish first version of tinycolor2 there
3. Get PRs with null safety and others over here, check and merge them

[TNorbury]

We should also take a look at the issues in the original repo and decide which ones will need to be migrated over

[calvintam236]

Done. I have left comment in those issues that require to be migrated over.

[calvintam236]

1. Edit the readme: creadit the previous authors of tinycolor package and adapt other stuff where needed

I think when they make a PR, they can add their name into README. We should make a CONTRIBUTING.

2. Set up organization on pub.dev and publish first version of tinycolor2 there

We can do this after updating the readme.

3. Get PRs with null safety and others over here, check and merge them

I have commented in the original PRs and let’s see if they are making a PR on this side soon.

[calvintam236]

I just added issue templates.

[calvintam236]

Created automated projects for feature requests and bug triage: https://github.com/TinyCommunity/tinycolor2/projects

[calvintam236]

Updated pubspec for the new repo name, new version and git repo url

[calvintam236]

Branch protection added. Dependabot alert has enabled.

[WieFel]

LGTM.

I think when they make a PR, they can add their name into README. We should make a CONTRIBUTING.

You mean a section "Contributing"?

[calvintam236]

https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors

[calvintam236]

@WieFel Should we add CI build testing?

[calvintam236]

For the package, I am using lint on my other projects. Not sure what is the difference from flutter_lints.

I am not sure either. flutter_lints is the official one proposed by the Flutter team. It is quite new. I think it's the successor of https://pub.dev/packages/pedantic
I would personally use flutter_lints...

I just did a diff between flutter_lints and lint, and lint has much more rules enabled than flutter recommended one. This finding surprised me. I think more rules are better?

@WieFel any thoughts?

[WieFel]

I'd prefer flutter_lints. The lint package doesn't seem to be that popular...

The only thing that I miss is a github action for flutter_lints. Maybe it is so new that there is no action yet.

[calvintam236]

I'd prefer flutter_lints. The lint package doesn't seem to be that popular...

The only thing that I miss is a github action for flutter_lints. Maybe it is so new that there is no action yet.

To lint on Flutter, you just run flutter analyze.

lint package has existed since Dart 2.2 was released. (pedantic disables a lot of linter rules; hence, lint was created by community.) flutter_lints was released since Dart 2.12.

One thing I am concerned on is tinycolor2 min Dart sdk version. Right now, it is for Dart 2.6+ (Flutter v1+), and flutter_lints would not work (Dart v2.12+).
Bumping from v2.6 to v2.12 is a major breaking change. It will remove support for people who are still using the older Flutter / Dart version in their project.

tinycolor2/pubspec.yaml

Line 7 in 89c7b9d

sdk: ">=2.6.0 <3.0.0"

I think we need to release v2.0.0 with no null-safety (fixing general bugs), and v2.1.0 (or v3.0.0) with null-safety (min Dart and Flutter SDK version will bump because of this).

[calvintam236]

@WieFel what do you think?

[WieFel]

I think flutter_lints suffices for our project. Our project is not that complex that we would need so sophisticated lint rules...
But whatever, if you insist in using lint package, go ahead.

One thing I am concerned on is tinycolor2 min Dart sdk version. Right now, it is for Dart 2.6+ (Flutter v1+), and flutter_lints would not work (Dart v2.12+).
Bumping from v2.6 to v2.12 is a major breaking change. It will remove support for people who are still using the older Flutter / Dart version in their project.

I don't think that is a major problem. If someone wants to use tinycolor2 over tinycolor it is most probably because of null-safety and new features. Our main goal is to bring null-safety to tinycolor. So if one switches from tinycolor to tinycolor2, they have to upgrade their project. It's as simple as that.
I think we can already release v2.0.0 with null-safety included.

[WieFel]

Later we could also create a small demo app and host it on github pages. Maybe my package https://github.com/WieFel/gallerize could be some help there!

[calvintam236]

@WieFel In order to create a publisher on pub.dev, we need to setup a domain (probably gh-pages with .github.io works) per https://pub.dev/create-publisher. I guess we need to setup a static site first?

[calvintam236]

@calvintam236 I think our first deployment of the package we have to do manually, as also noted here: https://medium.com/evenbit/publishing-dart-packages-with-github-actions-5240068a2f7d and here: https://github.com/marketplace/actions/publish-dart-flutter-package
Credentials need to be retrieved from .pub-cache.

So i think we would be ready!? We can add deployment action for version 2.0.1. Should we include lint already in version 2.0.0 or should we wait for 2.0.1 for that?

How about https://github.com/marketplace/actions/dart-and-flutter-package-publisher? This one can do test, format, and publish in one.

[WieFel]

How about https://github.com/marketplace/actions/dart-and-flutter-package-publisher? This one can do test, format, and publish in one.

• Well first we would need some tests. And in that case I think an isolated workflow only fot testing makes more sense.
• Formatting should already be done before committing something to the repo.

But I don't care, we can also use this action, as long as it is able to publish...

[WieFel]

So i think we would be ready!? We can add deployment action for version 2.0.1. Should we include lint already in version 2.0.0 or should we wait for 2.0.1 for that?

?

[calvintam236]

How about https://github.com/marketplace/actions/dart-and-flutter-package-publisher? This one can do test, format, and publish in one.

• Well first we would need some tests. And in that case I think an isolated workflow only fot testing makes more sense.
• Formatting should already be done before committing something to the repo.

But I don't care, we can also use this action, as long as it is able to publish...

In GH actions, you can setup different jobs in the same action file and also different action files. Writing tests should not be difficult at all in this package.

[calvintam236]

So i think we would be ready!? We can add deployment action for version 2.0.1. Should we include lint already in version 2.0.0 or should we wait for 2.0.1 for that?

?

Sure. It is fine to me

[calvintam236]

@TNorbury I think we need your help:

1. tinycolor2.dart (renamed from tinycolor.dart) only exposed file (single import for all library files) since we can’t use this PR (multiple feature changes and outdated)
2. for lint and CI we yet havent decided which way to go. I will update you.

[TNorbury]

Ok! I can make the changes for # 1. I can just wrap that into my already open PR.

[calvintam236]

I think we need to wait for null-safety one merged first before merging #4 (renaming files would cause conflicts). Or you can create a different PR just for the renaming.

[TNorbury]

Good call. I'll just wait until null-safety comes through.

[calvintam236]

@WieFel What should be our merge strategy? Merge commit or squash?

Read here: https://docs.github.com/en/github/administering-a-repository/configuring-pull-request-merges/about-merge-methods-on-github

[WieFel]

I'd go for simple merge commit, also due to the disadvantages listed under squash...

What do you think about this?

[calvintam236]

Merge commit for PRs, bugfix/hotfix and Squash for feature branches?

[WieFel]

Ok why not, go ahead

[TNorbury]

Another thing we'll want to do to prep for publishing the package is fix various things so we can get more pub points. The original package's score is here. But in short what we'll want to do:

• Fix a link in the Readme that isn't using https
• Create an example
• Pass static analysis (related to formatting, included in Update underlying color with setting alpha and opacity, and re-structure as library. #4 )
• Support null-safety (already done, just need that PR brought to this repo).
• (Already hit the checkpoint of >= 20% of public API's being commented. But I think it would be a good idea to increase that, especially since the main tinycolor.dart file isn't documented at all

[WieFel]

@calvintam236 @TNorbury check #13 for a first idea and first screenshots.
In my opinion, the example code is getting quite complex and is a little overkill for its purpose. Actually, the example code should be used to see the methods in action at one simple glance, without defining new widgets in separate files etc... Maybe we should keep the example more "static" and simply use one fixed color and apply the different methods to it, in order to show how they are used in code.

The idea of the more complex app (where the user can manipulate colors and press buttons etc.) would be more adapt for the "demo" app I mentioned above. That demo app could then be hosted on our github pages site as well, so that the user can try it out right away.

What do you think guys?

[calvintam236]

@WieFel you can build it for web and host it on GitHub pages for this repo (tinycommunity.github.io/tinycolor2).

[WieFel]

Yeah, but as I said I would personally rename the current example project to demo and host the demo on tinycommunity.github.io/tinycolor2.

As a new example I would create a very simple project consisting of one main.dart file that shows the basic usage of TinyColor class a few color transformation functions. Nothing more.

[TNorbury]

@WieFel Yeah, that makes sense to me. Good call, I think simple is definitely better for the example.

[WieFel]

Ok, will do

[WieFel]

@calvintam236 Package is now published! https://pub.dev/packages/tinycolor2

Secrets for CD have been added.
Should we create a tag for release 2.0.0? But when doing that, CD will be run, which we don't want... We could cancel action manually!?

[TNorbury]

I think you'd be able to create a new tag without CD running. Per the github action syntax at https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestbranchestags it sounds like tags are treated separately from releases? But yeah, if I'm wrong you could cancel the job haha

[calvintam236]

@WieFel Well you should create a pre-release/preview first on pub.dev. Anyways, you cannot undo it now. I think if you create a tag now, it will bump the version to 2.0.0+1. You can cancel the job to prevent that of course.

[WieFel]

@calvintam236 ok, will do.

Why pre-release?

[calvintam236]

pre-release have different version number and wont conflict with normal tag version

[calvintam236]

they usually end with .dev, .preview