-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added vendor dir for js/css libs; Documented sources (#1484) #2241
Conversation
The version of this file in use is located at: vendor/plugins/highlight/github.css
LGTM |
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.
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:
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. :) |
@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 |
@sapk in the future we should move to webpack to have single js file |
@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.") |
There was a problem hiding this 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> |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
With this I mean that for this PR I don't care, any updates in the future should use yarn though ;) |
@bkcsoft we could do that in an other PR. |
And in fact all the version are listed in archive link of librejs.html |
@sapk Why I hate PRs that touch 1.3k files 😂 |
Me too but in this case it is mostly rename. |
@sapk right, my point was that we need a file |
@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 |
LGTM |
This is ready to merge, why waiting for 1.3.0 ? I think it is worth having this ib 1.2.0 |
It's not tested well. I don't think move it to v1.2 is a good idea. |
@lunny This is a large PR, but I would encourage you to review what is being changed.
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? |
@MTecknology A file listing packages and versions. (no, |
@bkcsoft Your comment was about the file being removed. The file was not
removed, it was relocated and modified.
I already commented on the inclusion of an alternate option. It's a cool
idea. This PR is already big enough, isn't it?
It's a really big PR and, as I mentioned, I tried hard to keep it minimal.
I tried to keep out functional changes and keep it to documentation and
cleanup.
I disagree very much that this should be held up to wait for an entirely
new and undiscussed feature.
|
@MTecknology It's not a new feature, the version were tracked by the folder-names ( |
@bkcsoft That information /is/ in librejs.html... Why does that file "not count"? bits from that file:
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? |
Is a machine readable format you are after, @bkcsoft ? |
I found some links broken in librejs.html master version. If this PR will also fix that? |
@lunny Yes... The first commit in this PR:
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... :( |
@MTecknology My main quarel with having them listed in |
Awesome! |
And If you want to this in v1.2, please send a back port PR to branch release/v1.2 |
Furthermore integration tests are failing because of moved librejs file. |
Is drone not running integration tests ?
|
This now break until upstream accepts PR #2241 [1] and a new tarball is imported with the changes. [1] go-gitea/gitea#2241
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).