lack of semi-colons breaks bootstrap js files when tethering

Question

lack of semi-colons breaks bootstrap js files when tethering

cam-intel opened this issue 13 years ago · 13 comments

When using bootstrap across a tethered connection at least one js file stops working.

The reason is that many providers (o2, t-mobile, vodafone) across the world embed another js script into web pages. The script is called bmi.js.

This file helps compress many separate js requests into the main page.

The lack of semi-colons in the dropdown js file causes this compression to break, and the dropdown menus stop working on any device if the device is tethered.

The fix is simple: just use semi-colons. The line that breaks is

    clearMenus()
    !isActive &&  ...

saimonmoore commented 13 years ago

amen

Answer 1 · 2011-10-10T15:52:09.000Z

Are you saying your compressor doesn't add semicolons? that's crazy. You should use a new one! (yui, google closure, uglify.js)

Answer 2 · 2011-10-10T17:59:05.000Z

Just to be clear: it is not my compressor.

The bmi script is inserted by our evil mobile ISPs - there is nothing one can do to prevent it! (Other than VPN).

So it definitely is worth fixing if you want bootstrap end users to be able to use bootstrap while they are tethered.

Answer 3 · 2011-10-11T00:34:09.000Z

if your js isn't being compressed, then the following is valid:

  clearMenus()
  !isActive && ....

Answer 4 · 2011-10-11T00:36:12.000Z

Oh wait... i'm just now understanding... hm... so these devices inject a javascript file which does on the fly "compression" -- and this "compressor" isn't adding semicolons, but is removing new lines?

Answer 5 · 2011-11-09T04:17:57.000Z

I'm running into the same issue with the default JS min for Java's WRO.

I don't see why semi-colons aren't used to begin with. Your point isn't invalid (that a good compressor should account for this when removing line breaks) but I can't for the life of me see why you would avoid semi-colon usage here.

You're trading the stability of the framework in unknown environments for a couple hundred (if that) bytes of space saved. Is there some other reason semi-colons aren't being used?

Answer 6 · 2012-02-02T14:24:19.000Z

Stylistically it may be a preference, syntactically it may be perfectly valid, but in practice it causes real-world issues. I would appreciate re-consideration of your semi-colon policy.

Answer 7 · 2012-02-12T06:47:31.000Z

I'm just curious why this issue get closed.

Is it solved, or invalid?

Answer 8 · 2012-02-14T02:25:49.000Z

The reason it was closed is because semicolons were added to the end of lines in 1.4. In 2.0 we removed them again when we introduced the downloader as it safely concats and minifies these files for you. I'm adding semicolons to the end of files in 2.0.1 - which will likely be released tomorrow, to support this mobile oddity.

Answer 9 · 2012-02-14T02:45:01.000Z

Please don't take them out again. Stylistic preference or not, it would seem the wiser choice is to use them in a library meant for such a broad audience. I'm really glad to see you've reached the same conclusion for this particular issue.

Answer 10 · 2012-03-22T12:45:41.000Z

Add me to the list of people in support of semi-colons. Making assumptions about other tools in use is pretty foolish, it makes more sense to assume that your code is going to run on the lowest common denominator setup.

Answer 11 · 2012-06-22T15:51:50.000Z

Here we go again!

Answer 12 · 2019-01-04T08:58:15.000Z

our distributed JS files contains semicolons @elimin8r 😉