search

SAP-archive / grunt-openui5

Grunt tasks around OpenUI5
Apache License 2.0
90 stars 34 forks source link

Create -dbg files on build #44

Closed hagen closed 5 years ago

hagen commented 8 years ago

Hi @matz3

Enhancement: I'd like to also build the -dbg files for each controller/control in the built version of an app. This is simply a copy/paste/rename into the destination folder, but it means the ?sap-ui-debug=true flag will pick up the -dbg files for debugging productionised Fiori/UI5 apps.

Thoughts?

RiverSongFox commented 8 years ago

I'm not sure about production, because uglification is all about reducing size of application, but as option this would be definitely useful for development & testing stages.

hagen commented 8 years ago

The size of the application loaded into browser doesn't change - only the preload is loaded. The -dbg files remain unread. If however you reload with the debug query parameter a developer could debug a production issue using human-readable files rather than minified code.

Life saver for troubleshooting production issues.

On Friday, 9 September 2016, Nikolay Kim notifications@github.com wrote:

I'm not sure about production, because uglification is all about reducing size of application, but as option this would be definitely useful for development & testing stages.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SAP/grunt-openui5/issues/44#issuecomment-245813295, or mute the thread https://github.com/notifications/unsubscribe-auth/AE7D4PA-gCv_LnlN6S8t26-q5EZZxQaMks5qoNndgaJpZM4J4g_X .

Hagen Dittmer hagen.dittmer@gmail.com 0417 112 941

matz3 commented 7 years ago

Although this could be quite easily achieved by using e.g. grunt-contrib-copy it may make sense to add a new task.

The rename is actually not completely straight-forward, as view/fragment/controller files need special handling. A RegExp could look like this:

filepath.replace(/((\.view|\.fragment|\.controller)?\.js)/,'-dbg$1')

Feel free to suggest some task idea.

I think the tricky part is how this plays with the fact that you may not only want a copy/rename but also some minification on the "non-dbg" files.

But in case you have a preload file in place there should be either the case (production) to only load that file or (production debugging) to load all "-dbg" files.

So having each individual file in two versions (dbg/minified) doesn't really make sense to me. But as the runtime (currently) loads the "-dbg" files in debug-mode you need to have them unless you are okay with having a lot of 404 errors and the fallback to the "non-dbg" file.

hagen commented 7 years ago

To my mind, if you added a -dbg file to the build, you would only have the compressed Component-preload, and the individual -dbg files. You wouldn't also have a minified original file (Controller, for example). So if your app structure was:

Then your build would be:

Sounds alright? There'd be no need to have minified non -dbg js files. I won't get on to this straight away, but I will be adding it eventually for a project I'm working on.

On 28 September 2016 at 19:25, Matthias Oßwald notifications@github.com wrote:

Although this could be quite easily achieved by using e.g. grunt-contrib-copy https://github.com/gruntjs/grunt-contrib-copy it may make sense to add a new task.

The rename is actually not completely straight-forward, as view/fragment/controller files need special handling. A RegExp could look like this:

filepath.replace(/((.view|.fragment|.controller)?.js)/,'-dbg$1')

Feel free to suggest some task idea.

I think the tricky part is how this plays with the fact that you may not only want a copy/rename but also some minification on the "non-dbg" files.

But in case you have a preload file in place there should be either the case (production) to only load that file or (production debugging) to load all "-dbg" files.

So having each individual file in two versions (dbg/minified) doesn't really make sense to me. But as the runtime (currently) loads the "-dbg" files in debug-mode you need to have them unless you are okay with having a lot of 404 errors and the fallback to the "non-dbg" file.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SAP/grunt-openui5/issues/44#issuecomment-250116933, or mute the thread https://github.com/notifications/unsubscribe-auth/AE7D4Gcqc95_88DOxtbnJ7x2juheHwV5ks5qujKPgaJpZM4J4g_X .

Hagen Dittmer hagen.dittmer@gmail.com 0417 112 941

matz3 commented 7 years ago

Yes, this sounds right. Actually it would be even better to adopt the "Debug Mode" to just load the plain files (without "-dbg"). This way you don't need to rename the files at all.

@codeworrior this was already in discussion some time ago, right?

codeworrior commented 7 years ago

@matz3: yes, it was. But we saw two problems with it: http/2 support and files that intentionally have been excluded from the preload, esp. bigger 3rdparty files -> no final conclusion yet.

matz3 commented 7 years ago

@codeworrior Thanks. I get the issue with large third party scripts, but what is the exact problem with HTTP/2?

codeworrior commented 7 years ago

For http/2 we want to load individual files, but still benefit from minification. So the statement "There'd be no need to have minified non -dbg js files" doesn't hold true.

matz3 commented 7 years ago

Oh yeah, that's true. But at least when you use gzip the difference shouldn't be too big, right?

codeworrior commented 7 years ago

Regarding bandwidth, you're right. Regarding the memory requirements on mobile as well as regarding the magic in some JS engines (there are rumours that some of them compile a function differently depending on its pure implementation string length), it might be different. I only say might, as we didn't analyse this in detail yet.

Nevertheless, I also struggle with the current file layout. Especially with the introduction of source maps, it creates some additional hurdles. The point in time (and the project) where a source map is created might not be the point in time where the knowledge about the existence of debug sources is available. So neither can we guarantee that the source map can be updated by the minification step nor can the merge (that creates the source map) be sure whether at runtime the unmagnified source will be named -dbg or not. E.g. for the sap.fiori bundles (not part of OpenUI5), it only works by convention as we always minify.

[Update] My personal conclusion at that point in time was: the same content ideally never should change its name during whatever build process.

matz3 commented 5 years ago

I'm closing this issue, as the UI5 Build and Development Tooling is capable of doing this. It is not very likely that we will add this also to this grunt plugin.