Add webpacker `app/javscript/packs` folder structure support
What does this MR do?
This is a first step to make our javascript codebase compatible with webpacker.
What it does is write support to our current webpack custom implementation to load entry-points from a folder structure and conventions used in webpacker. We also move those files in this merge request to their correct location
Additional information
The following command can be used to list existing entry points:
ruby -e "puts Dir.glob('{app,ee/app}/assets/javascripts/pages/**/index.js')"
and the following to see where they should be moved to be webpacker compatible.
ruby -e "puts Dir.glob('{app,ee/app}/assets/javascripts/pages/**/index.js').map {|dir| dir.sub('app/assets/javascripts/pages', 'app/javascript/packs/pages') }"
# to to see both previous and new:
ruby -e "pp Dir.glob('{app,ee/app}/assets/javascripts/pages/**/index.js').to_h {|dir| [dir, dir.sub('app/assets/javascripts/pages', 'app/javascript/packs/pages')] }"
(after running this code it identifies 302
entry-points, but when running existing codebase in webpack (previous to this change) it display the following
... webpack : 267 entries from '/pages' automatically added to webpack output.
Use this to print a git mv
command with all entries moving from old to new (suitable to be executed several times until all branches are fully migrated to the new style):
ruby -e "Dir.glob('{app,ee/app}/assets/javascripts/pages/**/index.js').to_h {|dir| [dir, dir.sub('app/assets/javascripts/pages', 'app/javascript/packs/pages')] }.each {|old,new| puts \"mkdir -p #{File.dirname(new)}; git mv #{old} #{new}\"}"
# and this version to actually execute the commands (make sure you are running it from `gitlab` root folder:
ruby -e "Dir.glob('{app,ee/app}/assets/javascripts/pages/**/index.js').to_h {|dir| [dir, dir.sub('app/assets/javascripts/pages', 'app/javascript/packs')] }.each {|old,new| puts `mkdir -p #{File.dirname(new)}; git mv #{old} #{new}`}"
(after moving the files the number stays the same, so no idea if anything is broken here already, but whatever it is we are keeping it stable)
This MR is successful if, after moving, we don't break anything. This change will allow us to progressively start migrating our webpack configuration to be more in line to how webpacker expect it to be.
By going this route we don't introduce a big scary rewrite nor we make an all or nothing situation. Even if we decide in the end not to use webpacker, by adopting some of their conventions we make the code base more approachable to anyone familiar to Rails.
A bit of how webpacker works: https://prathamesh.tech/2019/09/24/mastering-packs-in-webpacker/
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done