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.

I haven't seen any other mention of it in the help section. What are the rules for those scripts?

No special rules for these, same as the regular rules.

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?

No rule against allowing non-library code from Greasy Fork. It's just not a very useful thing to do.

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

Yes, you have the option when updating a script.

On the library list they are marked as (library), but on the detailed page it's not as obvious.

I think it's prominent enough, also considering there's no install button.

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?

Libraries cannot be installed, so these have no effect.

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

It's not something prominently linked to from anywhere; just an extra feature authors can use.

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

Voting on them is meaningless.

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)".

This would not be possible due to caching, I think.

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.

You can do a code search for the library URL if you're interested.

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.

This is meant to be an additional feature authors can use. The primary way of using libraries is to reference a CDN. So I don't think these stats have meaning.

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.

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.

Fixed, and removed a few other things as well.

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.

All libs now say "Antifeatures".

Fixed. Somehow just got this backwards.

If re-use is a factor for libs, getting other peoples views is useful.

The primary purpose of the site is to distribute user scripts/styles. Providing reviews/stats on non-user-script scripts is outside of what I want to od.

The header is necessary to indicate the version and the license

If you provide a header with a version and license, the site will use it. If you don't, the site will make do without.