Uglify с анонимной функцией

У меня есть такой .js, и я его уплотняю:

'use strict';
!(function () {
  var object = typeof exports != 'undefined' ? exports : this;
}());

Когда я использую компилятор Google Closure, я не получаю никаких ошибок, а «это» ссылается на объект окна. Но когда я использую Uglify (с mangle true или false), он получает неопределенное значение для «этого» (поэтому объект не определен, и я получаю сообщение об ошибке). Кто-нибудь знает, почему?

По сути, я могу просто изменить это на окно, и оно будет работать, но меня беспокоят другие коды, библиотеки или что-то еще, что я буду уродовать в будущем.

Примечание. Я использую плагин grunt-contrib-uglify с параметрами: mangle: true, preserverComments: false, sourceMap: true.


javascript anonymous-function uglifyjs grunt-contrib-uglify
person Thiago Miranda de Oliveira    schedule 20.03.2015    source источник
comment
Так что же получается после минификации?   -  person zerkms    schedule 21.03.2015
comment
typeof exports != 'undefined' плохо. Сделайте это строгим с !==   -  person m59    schedule 21.03.2015
comment
@ m59 что ты имеешь в виду под плохим? Есть подробности?   -  person zerkms    schedule 21.03.2015
comment
@ m59 это неплохо, потому что оператор typeof обязательно вернет строку.   -  person Pointy    schedule 21.03.2015
comment
Вы, ребята, защищаете свободное равенство? Я подвергаю сомнению все, что знаю о программировании. Вы говорите, что это редкий случай, когда все в порядке только потому, что в данном случае это не может вызвать проблемы?   -  person m59    schedule 21.03.2015
comment
@ m59 ну, это плохо, если ваш Дуглас Крокфорд, я думаю :) Если вы хотите жить и отстаивать более строгий стандарт кодирования, то, во что бы то ни стало, живите долго и процветайте, но факт в том, что в данном случае это не будет иметь никакого значения.   -  person Pointy    schedule 21.03.2015
comment
@m59 Я ничего не защищаю. Я спрашиваю техническую причину, по которой вы не рекомендуете использовать здесь !-. Есть ли проблемы с этим в этом конкретном случае? это нормально только потому, что в данном случае это не может вызвать проблемы --- для разработчика нормально принимать обдуманные решения, а не просто следовать догмам (которые не имеют (или имеют?) вескую техническую причину)   -  person zerkms    schedule 21.03.2015
comment
Я не понимаю одержимости === и !== В большинстве случаев я знаю (действительно действительно знаю), какие типы я сравниваю, так почему я должен добавлять этот дополнительный = в первую очередь?   -  person mmgross    schedule 21.03.2015
comment
@mmgross (отказ от ответственности: это ирония судьбы) разве вы не знали, что оператор === быстрее, чем ==?   -  person zerkms    schedule 21.03.2015
comment
Кстати, кто-нибудь может указать мне, где в спецификации ES5.1 объясняется это поведение с use strict? Например, когда код strict, тогда thisBind это undefined. Провел там добрых 10 минут, но никаких следов.   -  person zerkms    schedule 21.03.2015
comment
Я тоже не понимаю одержимости микрооптимизациями, так что, наверное, виноват я. ;)   -  person mmgross    schedule 21.03.2015

Ответы (1)


arrow_upward
4
arrow_downward

Ожидаемое поведение:

с 'use strict'; контекстом функции является undefined, а не глобальный объект.

person zerkms    schedule 20.03.2015
comment
Действительно? Не знал этого. Моя главная проблема в том, что тот же самый код работает в компиляторе закрытия Google. - person Thiago Miranda de Oliveira; 21.03.2015
comment
@ThiagoMirandadeOliveira, что это за тот самый код? - person zerkms; 21.03.2015
comment
Извините за мой английский. Но в основном тот же код в Google Closure Compiler работает. - person Thiago Miranda de Oliveira; 23.03.2015
comment
Кстати, я заметил, что компилятор Google Closure удаляет «строгое использование» из всех файлов (не знаю почему). Вот почему это сработало. Спасибо за помощь! - person Thiago Miranda de Oliveira; 23.03.2015