Ckeditor5: [Safari 10.x] SyntaxError: Cannot declare a let variable twice: 'n'.

[Reinmar]

This error is thrown now on https://ckeditor5.github.io. And will be thrown in the docs once we enable minification there.

It's caused by Safari's https://bugs.webkit.org/show_bug.cgi?id=171041. The samples work fine on Safari 11 (which, unfortunately, is not available in the stable channel yet).

[Reinmar]

I added a temporary workaround for this in:

• https://github.com/CKEditor5/ckeditor5.github.io/commit/1ac0b5bc1f668676861ceb50843c1bd8e7e49f61.
• dfc9b95

[Reinmar]

According to https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Safari_11_0/Safari_11_0.html and http://www.techradar.com/news/macos-1013-high-sierra-release-date-news-and-features we should be getting Safari 11 next week. Let's hope it's true...

[Reinmar]

I'm adding this to iteration 12 because we need to decide whether we'll be adding the workaround to builds too.

[Reinmar]

Safari 11 was released, so we can remove these hacks just before the release of iteration 12.

[Reinmar]

Followup for https://github.com/ckeditor/ckeditor5/issues/603:

According to our analytics only 65% of ckeditor.com's visitors has iOS11 installed already so we may need to consider bringing back the workaround ;/

We need to consider switching the workaround back on at least for ckeditor.com and docs.ckeditor.com. WDYT, @fredck?

[fredck]

Right now, versions older than 11 represent exactly 1.12% of the sessions (1.56% of new users) on ckeditor.com for the last 7 days. Let's wait another week and check it again, to try to understand how fast people upgrade.

If we'll not see changes, we may decide to introduce the hack back, in the websites only, as you proposed.

[fredck]

New stats after one week (Oct 13 - Oct 19):

• iOS11: 2.51% of the sessions (3.87% of new users).
• iOS10: 0.97% of the sessions (1.51% of new users).

Previous week ():

• iOS11: 1.16% of the sessions (1.68% of new users).
• iOS10: 0.62% of the sessions (0.89% of new users).

So, these numbers can tell that we have more iOS users, which makes sense as we just brought something new to the market and people want to give it a try.

But, we can check the proportion of the versions... this week we have 1:0.39 (iOS11/iOS10) for new users, versus 1:0.52 from the previous week.

Therefore, we can notice that people are upgrading somewhat fast.

I'll be happy to update these stats a week from now.

[oleq]

Therefore, we can notice that people are upgrading somewhat fast.

The iOS11 adoption is very fast, actually. This shouldn't be a problem for us.

[fredck]

New stats after one week (Oct 20 - Oct 26):

• iOS11: 1.51% of the sessions (2.22% of new users).
• iOS10: 0.53% of the sessions (0.72% of new users).

The ratio dropped a bit more to 1:0.32.

[frutality]

Is there a workaround which we could use without changing ckeditor source code? Some of us should support Safari 10 still. It's not that old. It's previous version, lot of users have it.

[Reinmar]

The bug is so serious that the only workaround I can think of is to transpile let/const to var. This Babel's plugin should be enough – babel-plugin-transform-es2015-block-scoping. The good thing is that such a transpilation shouldn't increase the code size significantly.

[esbenp]

Anyone landing here, here is a way to include ckeditor5 for Safari 10.x using webpack.

1. Find your babel rule for js files, it probably looks like this

{
    test: /\.js$/,
    use: {
        loader: 'babel-loader'
    },
    exclude: /node_modules/,
},

now change it to

{
    test: /\.js$/,
    use: {
        loader: 'babel-loader'
    },
    exclude: /node_modules\/(?!(\@ckeditor)\/).*/,
},

This will run ckeditor through babel-loader

2. If you use babel-presets-env then make sure it includes Safari 10. As an example below is my config.

{
    "presets": [["@babel/preset-env", {
        "targets": {
        "browsers": [">0.25%, not op_mini all, safari 10"]
        }
    }]
}

3. Lastly, there is a Safari 10.x bug that must be fixed by configuring UglifyJS, so instead of

{
    optimization: {
        minimize: true,
    },
}

do something like this:

const UglifyJsPlugin = require('uglifyjs-webpack-plugin');

{
    optimization: {
        minimizer: [
            new UglifyJsPlugin({
                uglifyOptions: {
                    safari10: true
                }
            })
        ],
    },
}

The important part here being passing safari10=true to uglifyOptions to fix the Safari bug. You can read more about that bug here https://github.com/webpack-contrib/uglifyjs-webpack-plugin/issues/92