Sweetalert2: SyntaxError: missing = in const declaration

[projct1]

Version of package is 6.2.6
Firefox version is 50.1.0
http://joxi.ru/vAWYPzvHebndmW

[limonte]

For bug reports, please include a jsfiddle in order for us to be able to reproduce the issue.

JSFiddle template: https://jsfiddle.net/limon/ad3quksn/

[projct1]

I dont know how exacly reproduce my case in fiddle, because i use webpack and modules.
This error appear on stage, when i write this in main.js file window.swal = require('sweetalert2');

[toverux]

That's very unlikely that there is a syntax error in SweetAlert itself. Given the screenshot, I would say that this is a build issue, you're not compiling to ES 2015 source down to ES 5 in order to run in the browser.
Firefox has partial support for ES 2015 and I don't even know if that's enabled by default.

A valid configuraton for SweetAlert on Webpack 2 woud be to install babel-loader, and use something like that:

{
    test: /node_modules.*sweetalert2.*\.js$/, loader: 'babel-loader',
    query: {
        presets: [
            ['es2015', { modules: false }]
        ]
    }
}

Remove the , { modules: false } part on Webpack 1. On Webpack 2, this preserves ES 2015 modules while still doing the transpilation. This lets Webpack apply tree-shaking on the library.

[limonte]

I just bumped https://github.com/limonte/sweetalert2-webpack-demo to latest versions, all works fine.

[projct1]

Sigh, i very bad understanding how configure webpack and using laravel-elixir-webpack-official and my gulpfile deadly simple =) :

const elixir = require('laravel-elixir');

require('laravel-elixir-vue-2');

elixir(mix => {
    mix.sass('app.scss').webpack('app.js');
});

[projct1]

But, users, who are not using bundlers, will catch this error too?

[limonte]

It looks like a Firefox issue: http://stackoverflow.com/a/39045496/1331425

[projct1]

Maby, for more support, should change const to var or let? )

[limonte]

Fixed in v6.2.7. Thanks a lot @rorc for reporting this issue!

[limonte]

@toverux just to let you know what was the reason. I changed

  "jsnext:main": "src/sweetalert2.js",
  "module": "src/sweetalert2.js",

to

  "jsnext:main": "dist/sweetalert2.js",
  "module": "dist/sweetalert2.js",

[projct1]

Ok, thanks you too =)

[toverux]

@limonte this is a step back, back to the times where there were no jsnext:main and module entry. With 6.2.7 they've lost their utility and could have been even removed in profit of the old main :/

module is designed to point to the original source, or at least a source containing ES 2015 modules, which will let more control to the consumer on its build toolchain, and let tools like Webpack/Rollup do a smarter compilation (eg. tree shaking, even if that has no effect atm on SweetAlert due to its current structure, or it also provides better linking with the library than the legacy exports of the dist version).

Another inconvenient, for example: with the recently-added module, when I was using SweetAlert 6.2.6 in my application (compiled in minimified ES5), sourcemaps were showing me the original, beautiful, uncompiled source of SweetAlert. Now we'll see the intermediary, frozen ES 5 source of dist/sweetalert2.js.

In fact, with 6.2.7, we're restoring compatibility only with Webpack users that don't have a Babel setup for SweetAlert, and only them. For the rest of us, this is kind of a regression.

I see two options:

• Since module was an unforeseen breaking change (and I apologize for that), wait for the next major version to restore module and jsnext:main (so we stay fully compliant to semver) ;
• Apologize to users like @rorc and pray them to add a line or two of configuration to compile SweetAlert using babel-loader (as an exceptional case of force majeure).

[limonte]

@toverux Your feedback is highly appreciated and my vote goes for this option:

Apologize to users like @rorc and pray them to add a line or two of configuration to compile SweetAlert using babel-loader (as an exceptional case of force majeure).

I'll try to play with laravel-elixir and see why it doesn't use the Babel setup in it's config.

[toverux]

Cool!
Although I also prefer the second solution (much more convenient for recent setups), I must admit that it may generate some noise (like the two issues we got) and annoy some SweetAlert users like the OP. But technically speaking, yes, it's much better to let module bundlers access our original source, to push the JavaScript ecosystem forward.
Don't hesitate to ping me on Gitter if we need further discussions about this and other distribution-related issues!

Edit: oh, I may have a retro-compatible solution that brings a good compromise until next major. Will do some tests asap. I propose to keep the current state for now at least.

[toverux]

@limonte I just did some experiments.
My idea was to keep compiling ES 2015 into ES 5 (to keep retro-compatibility), but exposing the ES 2015 module untransformed (that's what ["es2015", { modules: false }] does in Babel.
With the original modules, Webpack can do a better job while linking the library (that was my point in the previous comments). Then, the import/exports are transformed in the Webpack-specific format.

However... after some tests, here's my conclusion:

• To keep retro-compatibility, I was still using ES 5, meaning that a big part of the motivation to provide a ES 2015 source is gone.
• Webpack is already doing a great job with the current UMD distribution, and the resulting JavaScript is technically the same from the consumer PoV (This is only the case because 1) Webpack is cool and ; 2) the library cannot be tree-shaked since it only exports a big functiono-namespace as the default export, and not separate symbols.)
• The resulting JavaScript was heavier using native modules at the source: 95 kB using modules and 75 kB using the UMD dist. But, but, I think that's just Rollup using shorter internal variable names, different indentation, etc, so that difference should vanish after minimification.

So. We still have the two solutions, because an intermediary one (ES 5 + ES 2015 modules) has zero advantages.
After those experiments, I think that we should keep distributing the UMD version for everyone, so let's forget about jsnext:main and module for now. These do not bring major advantages without breaking compatibility with an undeterminate number of users.

But the original idea is still the future we want. When next major arrives, we could restore src/sweetalert2.js as the entry point for module bundlers. And tell users to setup babel-loader.
After that, we'll be free to apply some changes in the API that allow tree-shaking (which is not possible with UMD and other legacy formats). For example, with some BC-breaking changes, an user that don't use the "queue" feature won't see Webpack including queue-related code. We can go further, even with styles, and the user could save lots of bytes at build time.

Sorry for those long paragraphs :)

[limonte]

Thank you for the great research @toverux !

But the original idea is still the future we want. When next major arrives, we could restore src/sweetalert2.js as the entry point for module bundlers. And tell users to setup babel-loader.
After that, we'll be free to apply some changes in the API that allow tree-shaking (which is not possible with UMD and other legacy formats). For example, with some BC-breaking changes, an user that don't use the "queue" feature won't see Webpack including queue-related code. We can go further, even with styles, and the user could save lots of bytes at build time.

This sounds like an awesome future! :)

After those experiments, I think that we should keep distributing the UMD version for everyone, so let's forget about jsnext:main and module for now. These do not bring major advantages without breaking compatibility with an undeterminate number of users.

So, if I understand you right, we should remove jsnext:main and module for now and bump a new release version, right?

[toverux]

So, if I understand you right, we should remove jsnext:main and module for now and bump a new release version, right?

Not necessary :) They have absolutely no effect right now, so, yes you can remove them, but that's not urgent. The best is to restore "jsnext:main": "src/sweetalert2.js" and remove the unused module.

[limonte]

@toverux Done: v6.2.9.

Is https://github.com/limonte/sweetalert2/issues/390 somehow related to whole this story with module field?