consider using rails-assets-jquery.nicescroll for vendor/assets/javascripts/jquery.nicescroll

I think using rails pipeline makes it easier to handle dependencies. We need to package it separately in debian as minified javascripts should have their corresponding source in the archive.

While rails-assets.org is an awesome service, I don't think we want to introduce an external dependency on their server for bundle install.

Isn't it similar to rubygems.org? Diaspora uses many rails-assets gems.

Similar, yes, but it's still an additional external dependency. @dzaporozhets doesn't like us to use GitHub forks in the Gemfile for similar reasons, but let's see what he thinks.

My personal opinion, I think rails-assets.org is awesome and would help us manage our non-Ruby dependencies, but I also get why can't/shouldn't.

If we decide to go this route, rails-assets-clipboard is also there (all javascript packages in bower is available via rails-assets.org)

rails-assets is a better fit then bower for rails projects IMHO

@pravi @rspeicher I am against relying on one more service for bundle install. It is enough troubles when rubygems.org has availability problems. I don't want to have extra SaaS dependency. Especially because GitLab is self-hosted solution. Until there is a superior advantage I rather keep our JS libs on rubygems and inside vendor.

@dzaporozhets how about mirroring gems in Gemfile.lock from gitlab.com? I don't know how much effort it takes, but just throwing an idea.

Rails Assets gems are auto generated, how about running the same service from gitlab.com?

If its too much effort, lets just continue the way things are right now.

@pravi I would like to continue the way it is now. I rather spend our resources on application itself and leave gem hosting for rubygems.

@dzaporozhets can there be a simple way of knowing versions of the assets? How about using the format given below?

jquery.nicescroll.js will be a symbolic link to jquery.nicescroll.js-version.js

This way, we can easily find out if the javascripts packaged in debian is in sync with gitlab or not. Currently if we have to find the version of the vendored assets, the only way is to open it and for some minified js files, that is also not possible.

Currently if we have to find the version of the vendored assets, the only way is to open it and for some minified js files, that is also not possible.

As a side issue to this, we should not be vendoring minified JS. It gets minified as part of the asset pipeline anyway.

@pravi is it required to use packages even for every js library we use? We anyway pack and minify everything in one js file

@dzaporozhets two things,

1. We need to ship corresponding non minified js files for each minified js we ship.
2. If someone already packaged a javascript, we should use that to avoid duplication.

So if you are including non minified javascript and it is not yet packaged, we don't have to package it.

@pravi yes but GitLab application will compress, minify and concatenate all JS in one file. Why do we need to change this behaviour for debian package?

@dzaporozhets that behaviour will not change. rake assets:precompile will be run during package installation. We are talking about linking packaged js files to vendor directory instead of using embedded js files (before we run rake assets:precompile) when we already have the js file packaged or is a minified js (for minified js, we package it and the link it).

@pravi ok I see. OK so how we can help you with minimal changes to GitLab. Use non-minified versions of js files in vendor?

I've opened https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2494 to begin vendoring only non-minified JS.

@dzaporozhets that would be great help. Also if we can add version numbers to the vendored files and making a symbolic link without version will help us track those who are already packaged (avoid duplication).

An example given below,

pravi@pirate:~/gitlab/vendor/assets/javascripts$ ls -l jquery.endless-scroll*
-rw-r--r-- 1 pravi pravi 4989 Jan 14 18:14 jquery.endless-scroll-1.4.8.js
lrwxrwxrwx 1 pravi pravi   30 Jan 19 11:39 jquery.endless-scroll.js -> jquery.endless-scroll-1.4.8.js
pravi@pirate:~/gitlab/vendor/assets/javascripts$

This is how so files are handled in /usr/lib

$ ls -l /usr/lib/libzip.so.1*
lrwxrwxrwx 1 root root    15 May 10  2010 /usr/lib/libzip.so.1 -> libzip.so.1.0.0
-rw-r--r-- 1 root root 43616 May 10  2010 /usr/lib/libzip.so.1.0.0

Also if we can add version numbers to the vendored files and making a symbolic link without version will help us track those who are already packaged (avoid duplication).

@pravi It would be hard to maintain and remember to follow this pattern. We want to keep development as easy as possible. So I would rather just use non-minified version of files in vendor.

@dbalexandre can you replace js files in vendor/assets/javascripts that are minified with non-minified version this week?

Milestone changed to 8.5

@dzaporozhets Sure! I'll work on this.

Reassigned to @dbalexandre

@dbalexandre You can take over my MR I mentioned above. Be sure that we replace the minified scripts with the same release versions so we're not breaking anything at the same time.

See https://github.com/gitlabhq/gitlabhq/pull/9889#issuecomment-172378217 for info about fuzzaldrin-plus.

@rspeicher I'll take care about the release versions. Thanks!

@dzaporozhets okay, can you provide a file with list of vendored js and their corresponding versions, like a Gemfile?

@pravi when @dbalexandre will replace minified versions you will be able to do it easily. Just list files in vendor dir and look into their versions

mentioned in merge request !2494 (merged)

mentioned in issue #3322 (closed)

mentioned in issue #3324 (closed)

mentioned in issue #3323 (closed)

Status changed to closed by commit d6682663

mentioned in commit d6682663

mentioned in issue #14450 (closed)

mentioned in issue #14634 (closed)

mentioned in issue #22121 (moved)

mentioned in issue gitlab#6211

mentioned in merge request !14785