Pub-dev: Prevent uploading empty templates

Created on 31 Jan 2019 · 19Comments · Source: dart-lang/pub-dev

https://pub.dartlang.org/packages/hello_plugin
https://pub.dartlang.org/packages/hello
https://pub.dartlang.org/packages/flutter_plugin_test
https://pub.dartlang.org/packages/test_flutter_plugin
https://pub.dartlang.org/packages/felix_plugin_demo
https://pub.dartlang.org/packages/hello_hello
https://pub.dartlang.org/packages/first_plugin
https://pub.dartlang.org/packages/libvia

All of these are completely devoid of any useful code, as they are mere templates.
Preventing the upload of empty templates will help reduce the package spam on pub.

Source

miyoyo

👍21

Most helpful comment

I think that a few steps could be taken to prevent such things from happening:

DENY uploading if the package's description is a default description

const defaultDesc = <String, String>{
  "A new Flutter project.": "flutter project",
  "A new flutter plugin project.": "flutter plugin",
  "A new flutter package project.": "flutter package",
  "An app built using Flutter for web": "stagehand flutter-web-preview",
  "A sample command-line application.": "stagehand console-full",
  "A starting point for Dart libraries or applications.":
      "stagehand package-simple",
  "A web server built using the shelf package.": "stagehand server-shelf",
  "A web app that uses AngularDart Components": "stagehand web-angular",
  "An absolute bare-bones web app.": "stagehand web-simple",
  "A simple StageXL web app.": "stagehand web-stagexl",
  "Have you been turned into a newt?  "
      "Would you like to be? This package can help. "
      "It has all of the newt-transmogrification functionality "
      "you have been looking for.": "dart pubspec example",
};

DENY uploading if the package's source is exactly the same as defaults
- maybe parse the source and see if it's equivalent to the default examples?
DENY uploading if the package's homepage points to an "illegal" domain

const invalidHomepages = <String>[
  "https://github.com/dart-lang/usage",
  "https://example-pet-store.com/newtify",
  "https://www.google.com"
];

DENY uploading the package if Pana scores too low
- The errors should be clear and explicit
WARN if the Readme is the default one, heavily penalize pana score (-5 at least) if it is the default one.

Maybe import package pedantic if the package is pushed to pub?

And finally, allow retraction of packages within a certain time frame, and/or if the package hasn't been depended on in X days. (I know the pub team isn't big on package unpublishing)

And of course, moderation could also be a solution, but then, it gets into the territory of "who is the authority on packages?"
But that could be solved using democratic processes and package scores.

What if, if the package score was under 50 or something, and a (not yet existing, #798 ) user rating is too low, the package could be vote-deleted? Of course, new packages would be protected from this process, that way, they have a fair window to fix issues and gain popularity before being at risk of deletion.

Here are examples of what a bad package would look like, vs a good package:

bad_example
good_example

miyoyo on 30 Jun 2019

👍7 ❤2

All 19 comments

Closely related to #1570.

isoos on 4 Feb 2019

I've got a few more of these:
https://pub.dartlang.org/packages/number_display
https://pub.dartlang.org/packages/rvengine
https://pub.dartlang.org/packages/helper
https://pub.dartlang.org/packages/timer_button_sreeraj
https://pub.dartlang.org/packages/flutter_paudio
https://pub.dartlang.org/packages/flutter_collapsible_toolbar
https://pub.dartlang.org/packages/flutter_collapsable_toolbar
https://pub.dartlang.org/packages/carousel_hero
https://pub.dartlang.org/packages/redux_sqlite

These have all been published between Feb 1 and now

GroovinChip on 4 Feb 2019

👍1

hmm, maybe it's better to come up with a moderation policy..

And if you find a nice package name squatted, you ask the uploader for ownership, or file a request to take ownership under given moderation policy.

@mit-mit, are you working on a package moderation policy?

jonasfj on 5 Feb 2019

👍1

https://pub.dartlang.org/packages/hello_private

WHY

GroovinChip on 7 Feb 2019

Pushing this back in priorities.

We'd like to have a voting/rating/feedback feature implemented first (https://github.com/dart-lang/pub-dartlang-dart/issues/798), and we could use that for moderating such packages after the upload.

Pana could detect if the readme is from template (https://github.com/dart-lang/pana/issues/129), but in such cases the package is unmaintained anyway, and the uploader likely does not care about it.

One tangent that may be worth to pursue in the short term: checking the homepage URL at the time of the upload, but arbitrary blocking that seems to just encourage entering random third-party sites. THe list above already has package with www.google.com as a homepage.

isoos on 13 Feb 2019

👍1

thumbert on 19 Jun 2019

👍1

An entire page, filled with subsequent empty/test packages that have had almost zero work put into them (likely following a tutorial)

// Edit 24 June

It just keeeeeeps pilin' on.
https://pub.dev/packages/dart1
https://pub.dev/packages/wq
https://pub.dev/packages/login_package // This is a flutter app, how.
https://pub.dev/packages/wq2
https://pub.dev/packages/new_library
https://pub.dev/packages/andoter_flutter
https://pub.dev/packages/test_lib_hait

// Edit 30 June: 👏 LESS 👏 TRASH edition

https://pub.dev/packages/search_api_yash
https://pub.dev/packages/main // I'll give you a tip: The title is actually accurate for once!

miyoyo on 22 Jun 2019

👍1

Because the previous post is getting way too long, I'll use a new one for this special edition: _a blast from the past!_... which means I've just gone to the last page and worked my way up till the first libraries I posted up there. Still, around 100!

miyoyo on 30 Jun 2019

👍3

Any good ideas for how to automatically detect packages that are essentially just templates?

We could easily forbid them at upload, if we can easily determine whether they are useful or not..

jonasfj on 30 Jun 2019

I think that a few steps could be taken to prevent such things from happening:

DENY uploading if the package's description is a default description

const defaultDesc = <String, String>{
  "A new Flutter project.": "flutter project",
  "A new flutter plugin project.": "flutter plugin",
  "A new flutter package project.": "flutter package",
  "An app built using Flutter for web": "stagehand flutter-web-preview",
  "A sample command-line application.": "stagehand console-full",
  "A starting point for Dart libraries or applications.":
      "stagehand package-simple",
  "A web server built using the shelf package.": "stagehand server-shelf",
  "A web app that uses AngularDart Components": "stagehand web-angular",
  "An absolute bare-bones web app.": "stagehand web-simple",
  "A simple StageXL web app.": "stagehand web-stagexl",
  "Have you been turned into a newt?  "
      "Would you like to be? This package can help. "
      "It has all of the newt-transmogrification functionality "
      "you have been looking for.": "dart pubspec example",
};

DENY uploading if the package's source is exactly the same as defaults
- maybe parse the source and see if it's equivalent to the default examples?
DENY uploading if the package's homepage points to an "illegal" domain

const invalidHomepages = <String>[
  "https://github.com/dart-lang/usage",
  "https://example-pet-store.com/newtify",
  "https://www.google.com"
];

DENY uploading the package if Pana scores too low
- The errors should be clear and explicit
WARN if the Readme is the default one, heavily penalize pana score (-5 at least) if it is the default one.

Maybe import package pedantic if the package is pushed to pub?

And finally, allow retraction of packages within a certain time frame, and/or if the package hasn't been depended on in X days. (I know the pub team isn't big on package unpublishing)

Here are examples of what a bad package would look like, vs a good package:

bad_example
good_example

miyoyo on 30 Jun 2019

👍7 ❤2

Besides the blatant sample projects, are there any packages on pub.dev that don't have a default description / README but are so trivial that it would be worth moderating? i.e. https://www.npmjs.com/package/is-even

PixelToast on 1 Jul 2019

What about filtering out low scoring packages from any search results on pub.dev (at least by default)? Whilst not removing or preventing the packages from existing, it would at least reduce the clutter from search results. As I understand it, scores on pub gradually reduce for packages that are un-used or-un-maintained. These may then also end up below the threshold and disappear from search results. Going forward, automated emails could be sent out to maintainers for packages that have not been updated or ever used and eventually purged.

amugofjava on 1 Jul 2019

@PixelToast Definitely are a few, but then again, if they're popular, who's the absolute authority on packages? That could be controversial

@amugofjava The issue with that is that, if the treshold is too low (say, 35), this system is (effectively) already in place.
Plus, it doesn't solve the issue of name-hogging, some might argue it makes it worse, because, someone might be looking around for a name by putting keywords in pub, get an idea that isn't already used, and, unfortunately, after making everything, realize that the name is hogged by a low quality, low visibility package (happened to me once)
Having a Score/Rating system allows for developers who carefully plan out their packages to effectively have _zero_ chances of being deleted (Just have a score above the treshold), with a grace period (the "new" period) to fix any issues, and the deletion is community instigated, which can allow for deletion with either very low, or zero, moderator intervention.

miyoyo on 1 Jul 2019

👍2

Awesome ideas so far, keep them coming!

However, I think we should separate some of the concerns:

1) Completing a tutorial with successfully publishing a package will be thrilling for many beginners, and I feel it would be slightly off-putting if at the end of the steps it would say: "We have recognized that you are using the tutorial's template, and we'll block your upload." Sooner or later the tutorials will adjust to this and suggest some random text in the patterns we recognize, and we will be likely not that much ahead of the game.

We should recognize the patterns, we should highly reduce their score, but blocking the upload may not be the best action.

2) It should be easy to unpublish a package. I think many of the packages we see here would be unpublished by their authors as soon as they could do that (especially if they'd receive a nicely worded request about it - and that's the reason we should definitely do the recognition part).

We are working on self-servicing packages ('discontinue' flag first, but unpublish is also on the roadmap).

3) We should enable "community pressure". Namesquatting, fighting against search spam, and also low-quality packages should be removed from search results (and sometimes should be unpublished). I'm really eager to hear ideas in this problem space, it should help us prioritize our work.

isoos on 2 Jul 2019

👍3

I'm not gonna lie, I'd prefer if such packages were never on pub in the first place, but you raise a solid point there.
The package score hit is a good idea, this allows (in conjunction with 3.) for cleaning up eventual forgotten tutorials easily.
How about, on detecting that the package is low quality, instead of being negative, show a positive message in the console saying something like

We have detected that your package follows common examples/sample code. 
If this is your first time publishing a package to pub, congratulations, it worked! 🎉
If you do not intend to maintain your package, please run `pub retract` within X days.

// EDIT: 6th July fresh batch!

https://pub.dev/packages/progress_bar_custom
https://pub.dev/packages/ifghsdufhfff // This one's name is so deep and so complex.
https://pub.dev/packages/flutterem
https://pub.dev/packages/flutter_notifications
https://pub.dev/packages/pia_framework_base
https://pub.dev/packages/app_info
https://pub.dev/packages/mstore
https://pub.dev/packages/wxx_plugin
https://pub.dev/packages/omgplugin
https://pub.dev/packages/pateo
https://pub.dev/packages/helper1

https://pub.dev/packages/flutter_common // One more common lib! We're at what, 20 of these?

// 22 July, get them while they're hot.

https://pub.dev/packages/search_picker // A flutter app, again.
https://pub.dev/packages/flutter_slider_custom
https://pub.dev/packages/hg_umeng
https://pub.dev/packages/flutter_base
https://pub.dev/packages/at_map
https://pub.dev/packages/toastutil
https://pub.dev/packages/helloflutter
https://pub.dev/packages/json_form

I'll include https://pub.dev/packages/global_state just because the description verbatim says

Global State is a wrapper library over Floop. It does exactly the same with a different name.

Then why did you publish that?

// 10 August, it just keeps happening and happening

Special mentions for:
the triple upload
Yet another util package but this time it's even lower quality docs-wise

miyoyo on 2 Jul 2019

👍1

Updating the list:
24 empty packages uploaded by email:[email protected]
https://pub.dev/packages?q=email%3Aelliot%40invertase.io

A whole bunch of template packages named "prompter_*"
https://pub.dev/packages?q=%22prompter_%22

aasaanapps on 12 Aug 2019

👍1

I know this issue is mainly to address another problem, but I think the solutions for this and for the issue I will present may be related.

I have compiled a list of packages where the homepage/repository points to a 404 page, or presents a url that is misleading or insecure.

My worries are that, packages without a repository are not as easy to verify the code. I am even more worried with packages that have a repository, but the code is not there, it gives the impression of someone trying to mislead the client developer.

I understand that a repository/homepage may exist at the time of the artifact upload, but removed latter. I don't have a clear approach or know what should be done with the cases bellow, but I think the removal from search and a warning to clients developers would be ok.
Most of the packages below have a low rating, but at least two have ratings around 70.

Empty repo
https://pub.dev/packages/ywz_blue_plugin
https://pub.dev/packages/zhn_scan
https://pub.dev/packages/flutter_fs
https://pub.dev/packages/flutter_googlefit
https://pub.dev/packages/flutter_adbrix

Points to wrong repository (points to flutter/plugins)
https://pub.dev/packages/ovuhome_webview_flutter
https://pub.dev/packages/multiple_image_picker

Points to google play
https://pub.dev/packages/flulm_auth

Points to an insecure website
https://pub.dev/packages/voice_recognition

That's all folks.

BugsBunnyBR on 31 Aug 2019

👍2

@BugsBunnyBR, I think this is outside the scope of this issue, but we do score packages lower if there is no homepage. This means lower ranking in search results.

jonasfj on 1 Sep 2019

@BugsBunnyBR, I think this is outside the scope of this issue, but we do score packages lower if there is no homepage. This means lower ranking in search results.

Should I open other issue then?

BugsBunnyBR on 1 Sep 2019

👍1

Was this page helpful?

0 / 5 - 0 ratings