Greasy Fork

I suppose this is a mix of questions and ideas related to libraries.

The external scripts page links to this: https://greasyfork.org/en/scripts/libraries

• I haven't seen any other mention of it in the help section. What are the rules for those scripts?
• Should they additionally be served from a separate path (e.g. /libs/ or /scrips/libraries/) and new libs enforce that url, so that long term the regex rule would not allow include of non-libs? Or you enforce that outside of regex?

• Can libs later be toggled and released as ordinary script on same url (or the other way around)?

• On the library list they are marked as (library), but on the detailed page it's not as obvious. The "this is a lib" sentence is not clearly separated from the normal user-written description. Minimum there should be a "type: lib" among the other info.

• Does "applies to" have any effect? Is @include * a recommended header?

• Is the "run-at" directive useful/required?

• Does it mean anything if libs require other libs?

• Wouldn't it make sense to drop the UserScript header for something like UserLibrary to clarify the different usage.

• I haven't seen any lib where main page shows votes. Are vote counting disabled?

• Is it technically possible to install libs as user-scripts, or should the install stats be dropped?

• More interesting would be to see "for each day, how many scripts on GF reference/require this" and possibly "number of http requests (not from GF-page)".

• Very relevant for the maintainer would be to get a list of all the referencing scripts. Possibly it could be a search criteria in the normal script search.

• If you index the "require" from each script, for script developers it could also be useful to get a "most required libraries" (both GF-hosted and others) to get some inspiration and show most trusted libs/versions.

The header is necessary to indicate the version and the license, but I think Applies to shouldn't be shown on the library's info page, @JasonBarnabe.

Thanks for considering my ideas.

Fixed, and removed a few other things as well.

All libs now say "Antifeatures".

https://github.com/JasonBarnabe/greasyfork/commit/171c1753a7800e811578398797add076825bae0a#diff-42e367131a1a998e9de038ebf5f25ec7564725a6de5f575eb75c6ebce796cbbfL84

Did you instead mean "!lib && anti"? (I think libs also should require strict mention of any antifeatures so not sure why you'd want the change at all though.) If you meant that the list should show even if empty, I think adding "n/a" or so would make it more clear. NOTE: Seems to affect also non-libs.

This is meant to be an additional feature authors can use. The primary way of using libraries is to reference a CDN.

I understand that allowing libs under the same framework as scripts was an easy way, considered good enough and not in the plans for a rework. I was surprised to see there were so many adding libs. I however don't get the impression that all scripts follow the general rules, i.e. being useful to many or protected from change.

On a separate note, adding ?version to the usage-check regex might be a good idea to enforce following the recommendation.

Voting on them is meaningless.

Why did you make this decision? If re-use is a factor for libs, getting other peoples views is useful.

You can do a code search for the library URL

Oh, I hadn't seen that feature. Perhaps a nice addition would be to add a direct search link to each libs page.

Btw, I found that the search box on the result page won't do a search, but return to the advanced search overview. It suggest it to search the same way again. https://greasyfork.org/en/scripts/code-search?c=429613-gm-polyfill

I don't think these stats have meaning.

My suggestion was to include both libs hosted on CDN and as well as GF. The meaning would be to show which libs are most relevant on GF. But it was just a feature suggestion and I understand that some GF-libs may seem unused if only referenced from scripts not public on GF.

The header is necessary to indicate the version and the license

Here's one without header. Looks like GF handles that fine (assuming things). https://greasyfork.org/en/scripts/430098-alihesari-s-notice-js-0-4-0

When libs have "UserScripts" header, I rather get the feeling that they are posted as libs by mistake. But I understand if you want it for legacy reasons. It was just an area of possible improvements I noticed.

Looks like GF handles that fine

Doesn't look fine to me. Without the header GF has to generate the version from the current date, which is not very useful, and there's no way to set the license.