HestiaPi / hestia-touch-one-ui

ONE UI files shown on the touch LCD
GNU General Public License v3.0
5 stars 7 forks source link

Build without minification #13

Closed gulliverrr closed 4 years ago

gulliverrr commented 4 years ago

@jaythomas This is more of a yarn feature request rather than a HestiaPi issue but I am asking in case you have a solution now as we have talked about it before. The problem is that the minified distributable web app folder (produced via yarn build) regenerates ALL files with code that appear completely different on GitHub history compare even for the smallest change on a single file.

Would this work for us? https://www.npmjs.com/package/react-scripts-plugin-no-minify

jaythomas commented 4 years ago

In the config file minification can be turned off. Keep in mind it will still bundle all the code together in two js files so you will still have a whole new files generate every build upgrade.

The way it works right now there is a file called app.xxxxx.js which contains all our javascript files and another one called chunk-vendors.xxxxx.js which contains all the vendor code. You can see this in the output from yarn build:

Screenshot from 2020-02-25 09-29-58

The app chunk updates when we modify our code and the vendor chunk only updates when we add new library code. You will see the hash number at the end of the file change when this happens (chunk-vendors-a4f2b59c.js to chunk-vendors-e0d2893d.js for instance) and the <script> tags in index.html are updated accordingly. In the case with the last modification both files were re-generated unfortunately as I included a debounce function into the vendor chunk and modified our code to use it.

What it sounds like you want to accomplish is to not necessarily stop the code from minifying but to break the chunks into smaller pieces so less modifications happen between distributions?

gulliverrr commented 4 years ago

My 'conern' is that whenever I move the contents of the dist folder to the main repository the changes are not visible unless I link to the commit on this repo that produced the files. The options I can think of now:

Any other suggestion is welcome

jaythomas commented 4 years ago

Disabling minification will make the code readable enough to see future changes. Try this change and have a look at the output of dist/js/app.68a9e80e.js:

diff --git a/vue.config.js b/vue.config.js
index 37b597c..9066877 100644
--- a/vue.config.js
+++ b/vue.config.js
@@ -2,6 +2,10 @@ const webpack = require('webpack')

 module.exports = {
   configureWebpack: {
+    optimization: {
+      // Minification
+      minimize: false
+    },
     plugins: [
       new webpack.DefinePlugin({
         MQTT_SERVER: JSON.stringify(process.env.MQTT_SERVER || 'localhost')

It may simplify your release workflow instead to make this repo a submodule of the main repo. You would have a subfolder in the other repo that points to a commit hash on this repo contains the contents of that commit. That way it is locked down to a version of this code. Then when you want to update what version it points to, you make a commit there to point it to a newer commit hash or tag.

cd submodule_directory
git checkout v1.0
cd ..
git add submodule_directory
git commit -m "Update submodule to v1.0"
git push
gulliverrr commented 4 years ago

Sorry for not getting back to you earlier. I will try the minimize: false way first and get back to this issue. Thank you!

gulliverrr commented 4 years ago

With minimize: false I believe versioning looks better but still the hash xxxxxxxx on the filename breaks continuity. I saw a few workarounds by renaming the files at the end of the build and I believe is safe in terms of LCD browser not caching the old copy. Do you have a suggested solution on this end too or words of wisdom to avoid?

jaythomas commented 4 years ago

@gulliverrr indeed you can disable the hash in the filename. I found this in the documentation for vue.config.js. It is turned on by default to bust caching on browsers whenever there is a new release, which shouldn't be a concern for us.

I've written up some code comments in my vue.config.js for clarity (you can apply this patch file using the git apply command):

diff --git a/vue.config.js b/vue.config.js
index 37b597c..4fd4e36 100644
--- a/vue.config.js
+++ b/vue.config.js
@@ -1,7 +1,13 @@
 const webpack = require('webpack')

 module.exports = {
+  // See the webpack config documentation for available settings
   configureWebpack: {
+    optimization: {
+      // Minification
+      // https://webpack.js.org/configuration/optimization/#optimizationminimize
+      minimize: false
+    },
     plugins: [
       new webpack.DefinePlugin({
         MQTT_SERVER: JSON.stringify(process.env.MQTT_SERVER || 'localhost')
@@ -11,5 +17,9 @@ module.exports = {
   css: {
     sourceMap: true
   },
+  // Keep the same filename across builds for ease of distribution
+  // Hashed filenames are for cache busting, which isn't a concern
+  // https://cli.vuejs.org/config/#filenamehashing
+  filenameHashing: false,
   publicPath: './'
 }

If you want me to create a pull request let me know!

gulliverrr commented 4 years ago

I'll keep the minimize: false option for the time being. Code is about 7% larger without minification and diff-proof. I also had to use --ignore-engines with all yarn commands to avoid update warnings (unless @jaythomas you advise against that).

jaythomas commented 4 years ago

It's largely just there to bug you to keep your yarn and node version up to date. You can ignore that by updating your yarn config file.

yarn config set ignore-engines true