Gatsby: Gatsby uglify not compatible with safari 10

[arturhenryy]

Description

Everthing works fine with my application expect that the finished build throws errors in
safari mobile <= 10.
SyntaxError: Cannot declare a const variable twice: 'e'

if i skip the uglification with gatsby build --no-uglify there are no errors.

Is there anyway to tell the uglifier to respect safari 10 rules like that?

    uglify: {
      uglifyOptions: {
        mangle: { safari10: true }
      }
    }

the only way that i can ship the app right now is without uglification which is not really a nice solution.

Environment

  System:
    OS: macOS High Sierra 10.13.2
    CPU: (4) x64 Intel(R) Core(TM) i5-7267U CPU @ 3.10GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 8.12.0 - /usr/local/bin/node
    Yarn: 1.12.3 - /usr/local/bin/yarn
    npm: 6.4.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 71.0.3578.98
    Firefox: 63.0
    Safari: 11.0.2
  npmPackages:
    gatsby: ^2.0.63 => 2.0.63
    gatsby-image: ^2.0.22 => 2.0.22
    gatsby-link: ^2.0.7 => 2.0.7
    gatsby-plugin-catch-links: ^2.0.9 => 2.0.9
    gatsby-plugin-feed: ^2.0.11 => 2.0.11
    gatsby-plugin-google-analytics: ^2.0.8 => 2.0.8
    gatsby-plugin-manifest: ^2.0.11 => 2.0.11
    gatsby-plugin-nprogress: ^2.0.7 => 2.0.7
    gatsby-plugin-offline: ^2.0.18 => 2.0.18
    gatsby-plugin-page-transitions: ^1.0.7 => 1.0.7
    gatsby-plugin-react-helmet: ^3.0.4 => 3.0.4
    gatsby-plugin-sass: ^2.0.7 => 2.0.7
    gatsby-plugin-sharp: ^2.0.14 => 2.0.14
    gatsby-plugin-sitemap: ^2.0.3 => 2.0.3
    gatsby-plugin-styled-components: ^3.0.4 => 3.0.4
    gatsby-plugin-twitter: ^2.0.8 => 2.0.8
    gatsby-remark-autolink-headers: ^2.0.12 => 2.0.12
    gatsby-remark-copy-linked-files: ^2.0.7 => 2.0.7
    gatsby-remark-images: ^3.0.1 => 3.0.1
    gatsby-remark-prismjs: ^3.1.4 => 3.1.4
    gatsby-remark-responsive-iframe: ^2.0.7 => 2.0.7
    gatsby-source-filesystem: ^2.0.11 => 2.0.11
    gatsby-source-wordpress: ^3.0.19 => 3.0.19
    gatsby-transformer-remark: ^2.1.15 => 2.1.15
    gatsby-transformer-sharp: ^2.1.9 => 2.1.9
  npmGlobalPackages:
    gatsby-cli: 2.4.5

[jgierer12]

Gatsby uses terser instead of uglify-es under the hood, but since it's a fork it should support also support the safari10 option. IMO we should just enable that option by default.

Edit: FYI Parcel also enables this by default.

[arturhenryy]

@jgierer12 thanks for the insight. are you a contributer to the gatsby project? and if so would you be able to do a pull request for this?
yeah i mean safari 10 is still common and should definitely supported. it took me quite sometime to figure out that the problem was the uglification and we could spare other people that work.

[sidharthachatterjee]

@arturhenryy Sorry for your issue. Just to confirm, does your site completely break in Safari 10? Just tested gatsbyjs.org on Safari 10 on iOS 10.3 and it seems to work fine.

Can you link to a minimal reproduction repo? I'm trying to ascertain if all Gatsby sites are broken or just some (that use specific features etc)

If the generated bundle size difference (between no support and default support for Safari 10) is really small, we'll add default support.

[pieh]

Can you try editing node_modules/gatsby/dist/utils/webpack-utils.js and find Terser config there and edit options to add mangle: { safari10: true } to see if this fixes the issue?

@sidharthachatterjee already opened PR with this change, but we don't have a way to verify it fixes the issue

[arturhenryy]

@pieh i edited the webpack-utils.js accordingly and i can confirm after deploying the responding build that it fixed the problem in safari 10.

[arturhenryy]

@sidharthachatterjee yes the page did stop loading after the described errors and resulted in a blank page. it might have been some gatsby plugin which is not integrated in the gatsby.org which caused the error post-uglification.

[arturhenryy]

@sidharthachatterjee should i compare the sizes of the builds or will you do that?

[pieh]

I'll compare bundle sizes with default starter. It would be great if you could do the same with your project, just so we have bigger sample size - and also the safari10 mangle option might be no-op for default starter if safari10 doesn't have issues with bundles produced for it

[pieh]

so as I suspected - this is essentially no-op for gatsby-default-starter - exactly same bundle sizes / content

[arturhenryy]

@pieh i can confirm this. same result when building with my repo

[sidharthachatterjee]

@arturhenryy Wait, do you mean it is the same content with your repo as well? Or just the resulting size?

[jgierer12]

I wonder why it even is opt-in in terser then. It must have some implications, right?

[arturhenryy]

@sidharthachatterjee the size. but yeah it fixes my issue

[pieh]

size could be the same - mangling change names to all those (usually) 1 letter names
and just reading mangle options:

safari10 (default false) -- Pass true to work around the Safari 10 loop iterator bug "Cannot declare a let variable twice"

there seems to be safari 10 bug where scope in loops isn't respected and safari think that variables in loop are redaclared, so this option just makes sure to not reuse same "mangled" variable name in loops as it already used in scope above that loop