Include different versions of Vue.js depending the environment

We should find a way to include vue.js conditionally. In development, we should include unminified version of vue.js to be able to use the Vue DevTools but in production we should include vue.min.js.

/cc @jschatz1

@grzesiek Can you please add your ideas we discussed in our session?

The options are

1. To include the right erb to include the asset. Something like: require_asset 'some_asset' if Rails.env.development?
2. Write a gem that does all this automatically for us and contribute it to the community.

Rails already minifies assets in production automatically. Check out the CSS and JS files this very page on gitlab.com include:

• https://gitlab.com/assets/application-c8a7a4d465ed3315520cb9ce5e8ab7289c06305bf73d6052bd49641b4afb6804.css
• https://gitlab.com/assets/application-9d3c9aae13880935e540f39d4ffa1484e2b2a47075d3002135c230923fb3c971.js

On your local GitLab installation, both of these will be unminified for easier debugging.

So as for Vue, we need to include the unminified vue.js in vendor/assets/javascripts, and Rails will do the rest. This is already what we're doing in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5022.

---

Edit: @jschatz1 points out to me over Slack that the issue isn't just minification, vue.js and vue.min.js are actually different in that the latter strips debugging statements that are in the former. We could do this:

// vendor/assets/javascripts/vue.full.js
// Full vue.js

// vendor/assets/javascripts/vue.min.js
// vue.min.js

<!-- vendor/assets/javascripts/vue.js.erb -->
<% type = Rails.env.development? ? 'full' : 'min' %>
<%= File.read(Rails.root.join("vendor/assets/javascripts/vue.#{type}.js") %>

// app/assets/javascripts/any_file.js
//= require vue

Because Rails will precompile the assets for production, the Ruby code in vue.js.erb is NOT executed on every page load, just on precompilation, so that the right file (vue.min.js) ends up in the fully compiled JS.

I thought about defining Vue asset name in app/config/environments/... to avoid hack with type and using if env in code.

Is it time for npm or bower so we can clean up vendor/assets too?

It would make this sort of thing a lot easier as it will allow us to specify development/testing deps and production deps separately.

Will also help with security as we don't know the libs that people are adding match the correct checksum if you catch my drift.

I second to @grzesiek. In general I don't like the idea of checking which environment we're running at the moment, because that would make creating another environment hard, and we would have conditions over the places. So setting the name in config/environments/development.rb and config/environments/production.rb and so on so forth would be preferable for me. Or we could check environment variables. I used to have a .env file to setup some additional global configuration based on environment variable, so it could be easily overwritten by env SOME=THING ./run app for example.

---

I used to have npm and bower along with Rails as well as @lbennett pointed out. The bad side of that is it's not playing very well with Rails assets pipeline, so beware of incompatibilities! As far as I know, the "Rails way" to do that would be using https://rails-assets.org/ which I am not a fan of, due to an extra layer and yet another thing we need to trust. But if it works...

@godfat Doesn't sprockets check and load (when required) anything in vendor/assets? If so we can just set the deps root directory as vendor/assets? Then npm i or bower i will just dump all of our deps in vendor/assets as they are currently.

@lbennett The thing is not everything could be handled by sprockets, i.e. rake assets:precompile could fail on some random stuffs installed by npm or bower. The first example popped from my memory is that jquery has some partial JavaScript in their repository, which they have some scripts to compile with, but sprockets tried to compile those partial JavaScript and then complaining about syntax error. There were also a lot of "special rules" I need to define to exclude from, which were not trivial and the rules could go on for various different packages. It's a pain to maintain them.

@lbennett Eventually we moved to webpack and ignored sprockets at all, for your reference :P

mentioned in merge request !5022 (merged)

mentioned in merge request !5845 (merged)

Status changed to closed by merge request !5845 (merged)

mentioned in commit fa576d38

mentioned in commit b09be748

mentioned in merge request !14785