Rexios

Hello! I'm the maintainer of Hive Community Edition.

I am proposing to introduce a new annotaiton called @GenerateAdapters. This allows you to generate TypeAdapters for types without explicitly annotating any types or fields. This is much easier to maintian and also allows generating adapters for types outside the current package.

For example:

@GenerateAdapters([
  AdapterSpec<ClassSpec1>(),
  AdapterSpec<ClassSpec2>(),
  AdapterSpec<EnumSpec>(),
])
void _() {}

This will generate type adapters for all the types specified. The main difference between using @GenerateAdapters and explicit annotations is that type IDs and field indexes are determined automatically. This information is then stored in a hive_schema.yaml file which informs future generations which type IDs and field indexes are in use.

My main concern is introducing this feature in a way that allows any future changes to be non-breaking. I believe I have eliminated most of the risk by basing the annotation off of mockito. At the moment there aren't actually any fields in the AdapterSpec class, but adding any in the future will not be a breaking change.

I would really appreciate any feedback the Hive community has on this. If you want to try out the @GenerateAdapters annotation to see how it works in your project, add the following to your pubspec:

dependency_overrides:
  hive_ce:
    git:
      url: https://github.com/IO-Design-Team/hive_ce
      ref: ec6e8d7dfc81a4adb3a9ae9eca0e78bc104116d8
      path: hive
  hive_ce_generator:
    git:
      url: https://github.com/IO-Design-Team/hive_ce
      ref: ec6e8d7dfc81a4adb3a9ae9eca0e78bc104116d8
      path: hive_generator

See the new documentation here

Note that this is a breaking change for the generator, as hive_registrar.g.dart has moved to hive/hive_registrar.g.dart to not clutter the lib folder. I have created a migration guide here

The pubstats.dev page keeps track of historical pub.dev data. I just made it so that it can also show the rank of a package on pub.dev based on its popularity score. For example dio is rank 20 right now.

If you haven't seen pubstats.dev before here are some other features:

• Like count and popularity score tracked over time for all packages on pub.dev
• Historical tracking of a lot of package metadata such as version and dependents
• Compare like count and popularity graphs across multiple packages (ex https://beta.pubstats.dev/#/packages/dio,http)
• If you sign in you can set up alerts for package info changes. Very useful for making sure you have maximum pub points! There are only Discord webhook alerts for now since that's what I use personally, but if you'd like to see more options feel free to contribute on GitHub.

As an added bonus, https://beta.pubstats.dev uses the new WASM renderer. Thanks to the Flutter team for helping me make that possible! There is some weirdness with Google OAuth still with WASM (see this issue), but everything else works. If you want to set up Discord notifications you might want to use the stable https://pubstats.dev for now.

Since Hive v2 has been abandoned and v3/v4 are nowhere to be seen I decided to hard fork Hive into Hive Community Edition (hive_ce, hive_ce_fluter, hive_ce_generator). Originally hive_ce was just going to be in maintenance mode to keep up to date with the evolving Flutter/Dart ecosystem (mainly Flutter WASM support right now), but there are some things that bothered me too much to ignore.

First of all... Hive v2 didn't support Sets. Why? I don't know but hive_ce does. Hive boxes natively support the Set type and the generator supports classes with Set fields.

One of the main pain points with TypeAdapters was remembering to register them all. Well forget no longer because hive_ce_generator generates an extension method on Hive to register them all in one go:

import 'package:your_package/hive_registrar.g.dart';

void main() {
  final path = Directory.current.path;
  Hive
    ..init(path)
    ..registerAdapters();
}

I posted about this package before and just got made fun of for the name, but this is a useful update for developers that work on large mono-repos on a daily basis. The puby link command used to require pubspec.lock files to be checked into version control in order to know which dependencies to grab, which most open source mono-repos do not allow. Notably, I work on the flutter/packages repo a lot and dealing with dependency resolution is a pain, but I just released an update to puby to fix this. This involves reusing the dependency resolution code directly from the pub command in order to catalog dependencies rather than relying on lock files. What this means in practice is you can have an empty pub cache, make a clean clone of the flutter/packages repo, and have all dependencies resolved in less than 30 seconds. The puby link command is now almost twice as fast as melos bootstrap and requires zero setup whereas melos likes to complain about your repository structure.

How is this legal? This has to be the most insecure login method I’ve ever seen. They removed the password from my account without consent and have no way to go back to requiring a password. Literally all an attacker has to do it gain control of either my phone/email and brute force a 4 digit pin. I’m going to have to change banks because of this.

Oh also I posted this on the bad version of Lemmy and the mod tried to claim that this method of auth is actually more secure than a password, posted a Wikipedia article about passkeys, and then locked the post… In no reality is it at all possible that this is more secure than a password.

So stay away from One Finance if you value your money

I’m using the iPad app in my Vision Pro and I can log in, but all the feeds just error out

Disclaimer: I made this

I spend a lot of time contributing to huge mono repos (flutter/packages, flutterfire, etc) and while some of them use melos to deal with the mess most of them don't. To help deal with this, I made puby.

Melos can be useful, but it requires project-specific setup so it's not good for repos that you don't control (and don't already have it set up). puby requires no setup, and you can run it literally anywhere. For example, if you keep all your dart/flutter projects in one directory you can execute commands in all of them at once by running puby in the root directory.

puby can do a lot, but here are the highlights:

Run any pub command

The first thing puby was made for is in its name: running pub commands. Run puby get, puby upgrade, etc to run those commands in all the projects in the current directory. Any extra arguments passed into puby will get passed to the commands puby runs. puby will automatically use the correct root command (dart/flutter) and even supports running with fvm if the project has it set up. puby combines the exit codes of the commands it runs, so it can be used to check for failures in CI.

puby link

puby link uses existing pubspec.lock files to catalog the dependencies required for all projects in the current directory, adds them to the pub cache, and then runs pub get --offline in all the projects in parallel. This can run up to five times faster than a regular pub get. This requires you to check in your pubspec.lock files to git, but the benefit is that when you switch branches a puby link will get you up to date in a few seconds.

puby clean

puby clean used to just be an alias for flutter clean, but since I added support for running commands in parallel for puby link it can now clean all projects in parallel as well. This is useful to clear out the cache of an entire monorepo, but it also has a much cooler use: cleaning up all of your local dart/flutter projects at once. Run puby clean in the directory containing all your local projects and you'll be surprised how much disk space you can reclaim.

puby exec

Run any command in all projects

Convenience commands

puby comes with many conventience commands to make common tasks easier

Outro

My team and I use puby every day. Please let me know what you think!

https://geekhack.org/index.php?topic=96232.msg3172021#msg3172021

I have a couple of these from a while ago and enjoy them a lot. Very excited to see them come back!

Disclaimer: I made this

I've been wanting a way to create type-safe Firebase rules for a while, so I made this package to let you do just that. I've used it for several of my projects now, and it's so much nicer than raw-dogging the rules syntax with no autocomplete. I was able to write rules from scratch without referencing the documentation once, and they deployed first try without any errors. I'm always hungry for feedback on my work, so please feel free to comment any feedback or suggestions.