Pub: [Discussion] Consider a convention making packages starting with _ invisible/not-advertized/hidden

[jonasfj]

Concept: Package names starting with _ (underscore) should not be advertised on pub.dev.

• they shouldn't show up in search results (except for exact name matches),
• they should have a package page, but not advertised to search engines,
  (similar to how "discontinued" works).

Obviously, this should be something we warn about in the pub client, if we want to make such a convention.

Use cases:

• We have some packages that are only used from generated code:
  
  
  
  • https://pub.dev/packages/_discoveryapis_commons (it's already used here)
  
  
  • https://pub.dev/packages/protobuf
  
  
• In https://github.com/dart-lang/pub/issues/2178 symbolic packages are proposed to give a single package two version numbers. This could worked around by publishing two packages, and this feature could be used to avoid polluting the pub.dev namespace and search results.

[amirh]

Another use case: dummy packages, e.g packages like _min_android_sdk_version/_min_ios_sdk_version can be used to augment the dependency graph with the platform requirements of different Flutter plugins. (right now if a plugin requires a higher Android SDK than what the app supports it will blow up late in the pipeline, and pub doesn't help the app developer to avoid the problem)

[natebosch]

I think the pub site already does this. For example _bazel_codegen doesn't show up in search as far as I know.

https://pub.dev/packages/_bazel_codegen

[jonasfj]

@natebosch, I believe the reason _bazel_codegen doesn't show up is that it has been flagged discontinued.

This would effectively be the same feature, but without labelling the package _discontinued_.

[isoos]

pub.dev has a doNotAdvertise flag, which we do not expose right now, but we could, similar to the isDiscontinued flag. We don't need to put that into the name of the package.

[jonasfj]

We don't need to put that into the name of the package.

Correct, but the motivation for putting it in the name is that:
(a) We're already doing it in a few places,
(b) Hidden packages shouldn't be squatting attractive package names,
(c) In Dart _ prefixed identifiers signals visibility, making this a nice complement.

[natebosch]

Weird, I thought we had given it that name specifically so it wouldn't show up in search... I do see that the discovery apis package shows up in search so either I was mistaken or something has changed.

[isoos]

(c) In Dart _ prefixed identifiers signals visibility, making this a nice complement.

It also makes the ordering of package imports a bit off.

[jonasfj]

I think the idea of being able to "hiding" or "lower the visibility" of some packages on pub.dev have multiple use-cases:

• Support packages for generated code _discoveryapis_commons,
• Symbolic packages that gives a single package two version numbers (#2178),
• Dummy constraint packages to express incompatibilities (_min_android_sdk_version)

My two cents for implementation is that we do either:
i) A _<name> naming convention as proposed here (See (a) through (c) in https://github.com/dart-lang/pub/issues/2184#issuecomment-518398123)
ii) A doNotAdvertize flag on pub.dev/packages/<packageName>/admin which can be set/unset by the owners of the package (once logged in on the website).

One of the upsides to (ii) is that we can easily remove if it few packages are using it. And packages can change visibility preferences.

[isoos]

+1 for doNotAdvertise. (It is also less surprising for new uploaders if they were to chose a weird name.)

We could also set this automatically for packages with _ as a prefix, but then the owners could update the flag if they need it.

[jakemac53]

I like the idea of a general admin interface on the pub site if we are willing to go that route. This would open the door for future self service features such as blacklisting bad versions of your package etc.

[amirh]

+1 to doNotAdvertize - another upside of this is that an author can decide to hide a package after publishing it (e.g they may not realize early enough that there's no point for the package to show in search results).

[jonasfj]

@jakemac53,
A general admin interface is already happening :)
As we are introducing self-serve features like transfer ownership to publisher. And flagging your packages as discontinued.

[amirh]

Sorry I misunderstood the proposal - my preference would be a pubspec.yaml flag.
I can imagine a template for federated plugins where the platform interface comes with this flag set already, I would worry that if devs need to go to the pub website and set this flag not all will do so which may result in search result clutter.

[natebosch]

my preference would be a pubspec.yaml flag.

What should the behavior be when there are multiple versions published with different values for the flag?

[amirh]

my preference would be a pubspec.yaml flag.

What should the behavior be when there are multiple versions published with different values for the flag?

Good point 😞

[jonasfj]

What should the behavior be when there are multiple versions published with different values for the flag?

hmm... I think that could be resolved by using the value from the latest version. That's what we do for package _description_, dependencies, platform classification, etc.

[isoos]

I think that could be resolved by using the value from the latest version. That's what we do for package description, dependencies, platform classification, etc.

Those attributes are closely attached to the publish-time state of the code. Whether a package should be visible in search seems to be detached from the state of the code, and could change over time (in both direction). It feels weird to control that state in pubspec.yaml.

[jonasfj]

Whether a package should be visible in search seems to be detached from the state of the code, and could change over time (in both direction).

I think that's the argument.