Better mapbox minification fix #2792
Conversation
... and run full compress otherwise.
|
Good find! While we’re at it, would it be worth including all trace types in that test? The Also, is it possible to base this flag on whether mapbox is in the bundle definition, rather than naming specific bundles? I wouldn’t want to have to remember this if we add another that includes mapbox. Or should we just leave this option in all bundles? Does it add a noticeable number of bytes? Anyway it says IE10 and below might not like this compression so it may be best to just make it consistent. |
- for consistency and maintainability, this does lead to a few extra bytes though.
... for better min.js test coverage
I hope you like dd8bf6c and 89d7aa8 where I reused the
That's what I went for in the end in 2a3afe7. I find the maintainability gains very nice here. It does adds a few bytes (noticeable in some but not all bundles). For reference, in red is with
|
|
😍 love it! Funny that in at least one case (Cartesian) minified is bigger but gzipped is smaller this way!? |
- to improve log readability - to keep cpu levels somewhat constant throughout run
| @@ -29,13 +29,13 @@ case $1 in | |||
|
|
|||
| jasmine) | |||
| npm run test-jasmine -- --skip-tags=gl,noCI,flaky || EXIT_STATE=$? | |||
| npm run test-bundle || EXIT_STATE=$? | |||
There was a problem hiding this comment.
⚖️ 👍
💃 still applies :)
fixes #2787, though I wouldn't call it a great fix, but it's probably the best we can do in this repo.
By playing around with terser's compression options (which is the default minifier in our dev-dep minify-stream), I found that setting
typeofs: falseon bundles that include mapbox-gl fixes #2789. Moreover, I added a test to make sure this doesn't happen again.With this PR our bundle sizes are back to where they were before #2789.