Skip to content

Conversation

MTecknology
Copy link
Contributor

This PR resolves #1484 and moves vendor'ed javascript (and other) libraries to public/vendor/. It also moves the documentation to vendor/librejs.html and includes documentation for both js and non-js libs.

With this commit, it is easy to prove only free/open-source libraries are being used by gitea, which helps meet GNU ethical repository criteria (#1524).

This commit mostly addresses #1484 by moving vendor'ed plugins into a
vendor/ directory and documenting their upstream source and license in
vendor/librejs.html.

This also proves gitea is using only open source js/css libraries which
helps toward reaching #1524.
The version of this file in use is located at:
  vendor/plugins/highlight/github.css
@bkcsoft bkcsoft added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Jul 31, 2017
@sapk
Copy link
Member

sapk commented Aug 1, 2017

LGTM
Just, why do you choose to put all under /plugins ? Why not keep some under sub-folder /libs like jquery, vue or semantic ?

@bkcsoft bkcsoft added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Aug 1, 2017
A SafeJS function was added to templates/helper.go to allow keeping
comments inside of javascript.

A javascript comment was added in the header of templates/base/head.tmpl
to mark all non-inline source as free.

The librejs.html file was updated to meet the current librejs spec. I
have now verified that the librejs plugin detects most of the scripts
included in gitea and suspect the non-free detections are the result of
a bug in the plugin. I believe this commit is enough to meet the C0.0
requirement of #1534.
@MTecknology
Copy link
Contributor Author

MTecknology commented Aug 2, 2017

@sapk

There were times where the CSS components weren't kept with the JS bits, but that wasn't consistent. I moved each lib into it's own directory partly to add consistency; I also wanted to be able to include a license file for each vendor'ed library to clearly identify each project as a separate work and clearly show the license terms of that source (which also helps meet license terms).

I kept them under plugins/ instead of breaking them into the other sub-directories because I wasn't able to discern the logic to the current layout.

Example:

jquery-1.11.3 was under public/js/
jquery.are-you-sure was under public/js/libs/
two other jquery libs were under public/plugins/<lib-name>/

public/js/libs/
    clipboard-1.5.9
    emojify-1.1.0
public/plugins/
    highlight-9.11.0
    simplemde-1.10.1

Even in the source, I couldn't find a reason why they should be considered different. Sorry, I didn't mean to get long-winded or ranty... just wanted to thoroughly explain my logic. :)

@sapk
Copy link
Member

sapk commented Aug 2, 2017

@MTecknology ok not a problem just to know if there were any reason. But effectively there wasn't before also ^^. Maybe we should think of using versionning for web ressources like npm or bower in the future. (not sure everyone will aggree with me ^^). still LGTM

@lafriks
Copy link
Member

lafriks commented Aug 2, 2017

@sapk in the future we should move to webpack to have single js file

@MTecknology
Copy link
Contributor Author

MTecknology commented Aug 5, 2017

@lafriks I agree! It'd be nice to have a nice json file (or two) with a pretty script to update all libs and run unit testing. If we had that, librejs.html could be turned into a dynamic file that's built by reading existing json files. (sounds great for a lot of reasons)

For now, though, it'd be super if this could make it into 1.2.0. It'd make my life a whole super duper lot easier. :)

(P.S. I actually don't care that much about the last commit. I hope to never touch that librejs plugin again... sticking w/ noscript. I just happened to be "in the neighborhood.")

Copy link
Member

@bkcsoft bkcsoft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A part from the question. There's no file listing which versions we have. This have to exist for this to be merged. I don't care if it's a real package.json/yarn.lock or just a plain-text file listing them, but it absolutely have to exist.

@@ -1,84 +0,0 @@
<!DOCTYPE html>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why has this file changed?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has moved under public/vendor/librejs.html

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As requested => the VERSIONS file

@bkcsoft
Copy link
Member

bkcsoft commented Aug 8, 2017

don't care if it's a real package.json/yarn.lock or just a plain-text file listing them

With this I mean that for this PR I don't care, any updates in the future should use yarn though ;)

@sapk
Copy link
Member

sapk commented Aug 8, 2017

@bkcsoft we could do that in an other PR.

@sapk
Copy link
Member

sapk commented Aug 8, 2017

And in fact all the version are listed in archive link of librejs.html

@bkcsoft
Copy link
Member

bkcsoft commented Aug 8, 2017

@sapk Why I hate PRs that touch 1.3k files 😂

@sapk
Copy link
Member

sapk commented Aug 8, 2017

Me too but in this case it is mostly rename.

@bkcsoft
Copy link
Member

bkcsoft commented Aug 8, 2017

@sapk right, my point was that we need a file public/vendor/VERSIONS that just lists all versions. Since I had no idea that librejs.html had that, and therefore no one else knows that either 😉

@MTecknology
Copy link
Contributor Author

MTecknology commented Aug 8, 2017

@bkcsoft I think I already responded to most of those concerns. I agree, librejs.html should be dynamically generated from the output of a tool that can keep JS libs up to date. (hopefully choosing a tool that can output a "versions" file)

I also think that's something much better suited for a different PR. I tried to keep this PR to just file moves and documentation--it's big, but I tried for minimal. librejs.html wasn't listed as a move because the file contents changed almost entirely.

Also, in the future, it'd be nice to apply a template to the rendered page so it's not just a boring table but a themed page with <table>[...]</table> as the page body.

@lunny lunny added this to the 1.3.0 milestone Aug 16, 2017
@strk
Copy link
Member

strk commented Aug 16, 2017

LGTM

@tboerger tboerger added lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels Aug 16, 2017
@strk
Copy link
Member

strk commented Aug 18, 2017

This is ready to merge, why waiting for 1.3.0 ? I think it is worth having this ib 1.2.0

@lunny
Copy link
Member

lunny commented Aug 18, 2017

It's not tested well. I don't think move it to v1.2 is a good idea.

@strk
Copy link
Member

strk commented Aug 18, 2017

@lunny 1.2.0 could be the first version with a proper Debian package, but I've understood a Debian package depends on this PR, for licensing issues.

#2285 was more dangerous to put in 1.2.0, if you ask me, as I suspect it's what broke the UI (#2331)

@MTecknology
Copy link
Contributor Author

@lunny This is a large PR, but I would encourage you to review what is being changed.

  1. Moved 3rd party libs to designated directory
  2. Updated path references to match
  3. Created/updated library documentation
    3a. Added missing LICENSE files
  4. Fixed issues for librejs users

This PR addresses some licensing concerns that, as @strk mentioned, are blockers for other bugs--one of those being a proper Debian package. I intentionally kept this changeset as small as possible to prevent this problem. I don't know what additional testing can be performed; if you tell me, I'll do my best to make it happen.

@bkcsoft You still have "changes requested," but I do not see what changes you are requesting. Could you please tell me so that I can make them?

@bkcsoft
Copy link
Member

bkcsoft commented Aug 19, 2017

@MTecknology A file listing packages and versions. (no, librejs.html does not count 🙂 )

@MTecknology
Copy link
Contributor Author

MTecknology commented Aug 19, 2017 via email

@MTecknology MTecknology mentioned this pull request Aug 21, 2017
7 tasks
@bkcsoft
Copy link
Member

bkcsoft commented Aug 21, 2017

@MTecknology It's not a new feature, the version were tracked by the folder-names (jquery-1.1.3 etc), but now that information is removed and needs to be added back in some form. And as I've said, it does not have to be yarn/npm, just a straight up flat file listing deps and versions...

@MTecknology
Copy link
Contributor Author

@bkcsoft That information /is/ in librejs.html... Why does that file "not count"?

bits from that file:

 +          <td><a href="https://github.com/codedance/jquery.AreYouSure/archive/1.9.0.tar.gz">jquery.areyousure-1.9.0.tar.gz</a></td> 
 +          <td><a href="https://code.jquery.com/jquery-1.11.3.min.js">jquery-1.11.3.min.js</a></td> 
 +          <td><a href="https://github.com/Semantic-Org/Semantic-UI/archive/2.2.1.tar.gz">semantic-UI-2.2.1.tar.gz</a></td>
 +          <td><a href="https://github.com/zenorocha/clipboard.js/archive/v1.5.9.tar.gz">clipboard-1.5.9.tar.gz</a></td> 

Are you looking for an additional file? Would you prefer I create librejs.yml to sit beside librejs.html that include the same information and adds an extra field just for the version?

@strk
Copy link
Member

strk commented Aug 21, 2017

Is a machine readable format you are after, @bkcsoft ?

@lunny
Copy link
Member

lunny commented Aug 22, 2017

I found some links broken in librejs.html master version. If this PR will also fix that?

@MTecknology
Copy link
Contributor Author

@lunny Yes...

The first commit in this PR:

This commit [moves] vendor'ed plugins into a vendor/ directory and document[s] their upstream source and license in vendor/librejs.html.

I'll say this again... very little actually changes in this PR. It's documentation and licensing crap. Please, look at what files changed and what file changes took place. I tried very hard to make this PR very easy to review for these exact reasons... I thought I'd succeeded... :(

@bkcsoft
Copy link
Member

bkcsoft commented Aug 23, 2017

@MTecknology My main quarel with having them listed in librejs.html is because that file is not where I'd expect to find that information. Since you've now added a VERSION file this LGTM 🙂

@bkcsoft bkcsoft merged commit a915a09 into go-gitea:master Aug 23, 2017
@lofidevops
Copy link

Awesome!

@lunny
Copy link
Member

lunny commented Aug 23, 2017

And If you want to this in v1.2, please send a back port PR to branch release/v1.2

@gsantner
Copy link

I'm on current HEAD and there are things broken. I think it's related to this one

unbenannt

@daviian
Copy link
Member

daviian commented Aug 23, 2017

Furthermore integration tests are failing because of moved librejs file.

@strk
Copy link
Member

strk commented Aug 23, 2017 via email

@daviian
Copy link
Member

daviian commented Aug 23, 2017

@strk @tboerger mentioned that integration tests currently run only on master branch...

MTecknology added a commit to go-gitea/debian-packaging that referenced this pull request Aug 1, 2018
This now break until upstream accepts PR #2241 [1] and a new tarball
is imported with the changes.

[1] go-gitea/gitea#2241
@go-gitea go-gitea locked and limited conversation to collaborators Nov 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unsourced/undocumented libraries; missing license files; and other issues

10 participants