Three.js: Файл "externs" компилятора Google Closure для three.js?

Нет, у three.js нет никаких внешних зависимостей, поэтому в чем-то подобном пока не было необходимости.

Я знаю, но для собственных проектов также полезно интегрировать THREE.js в компилируемую среду.

Как бы выглядел такой файл? Извините, если это уже объяснено по ссылке, которой вы поделились, я обнаружил, что страница немного перегружена (слишком много текста), и я не могу прочитать / понять.

@mrdoob , вы можете найти некоторые из их примеров по адресу:

http://code.google.com/p/closure-compiler/source/browse/#svn% 2Ftrunk% 2Fexterns

или

http://code.google.com/p/closure-compiler/source/browse/#svn% 2Ftrunk% 2Fcontrib% 2Fexterns

а также важно следующее:

http://code.google.com/closure/compiler/docs/js-for-compiler.html

Комментарии / заголовки? Я думаю, это затруднит чтение кода ...

Да, но я думаю, что это только для этого внешнего файла, а не для всего кода. Это можно сделать, но в этом нет необходимости.

Я пробовал это с http://www.dotnetwise.com/Code/Externs/index.html . Но он не работает полностью с Three.js. Не все определения извлечены.

Вот запись в блоге:

http://blog.dotnetwise.com/2009/11/closure-compiler-externs-extractor.html

Похоже, он поддерживает шаблон this.method = function(){} , но не прототипы ...

@mrdoob , как вы порекомендуете интегрировать THREE.js в собственное приложение с расширенным оптимизатором компилятора закрытия? Правда ли, что в настоящее время это невозможно?

Насколько я понимаю, расширенный оптимизатор включает только используемые классы, верно? По идее должно работать ... не работает?

Я не пробовал расширенную оптимизацию с помощью three.js, но я помню, что другие вещи использовались для взлома кода. В общем, это было небезопасно - с простой оптимизацией по умолчанию она всегда работает, с расширенной иногда - нет.

Он нарушает код, если вы компилируете его как библиотеку, но как приложение (с вызываемыми методами и всем остальным) оно должно работать, верно?

@mrdoob, чтобы использовать библиотеку со скомпилированным (оптимизированным) кодом, вам нужен «externs» -файл для объявления всех классов и методов библиотеки. Без него не работает. Но есть ли другой инструмент, который работает с three.js? Мне это нужно, чтобы скрыть (скрыть) мое приложение three.js. Один из кандидатов: https://github.com/mishoo/UglifyJS . Но я не пробовал.

Google closure externs - это файл, который описывает целые объекты, которые мы будем использовать в нашем скомпилированном коде.
Без этого файла компилятор просто делает из имен функций что-то вроде a () или b ().

Например, это для JQuery: http://code.google.com/p/closure-compiler/source/browse/trunk/contrib/externs/jquery-1.7.js

Было бы здорово, если externs будет для three.js.

Мне это нравится, но я не могу справиться с этим сам. Кому-то еще нужно будет подойти к этому вопросу.

@yurikor , когда вы используете node.js, вы можете использовать node-browserify и uglify-js вместе. Тогда ничего строить не нужно.

@remoe Большое спасибо за совет. Я попытаюсь.

Эта проблема некоторое время не использовалась, но на случай, если кто-то захочет решить эту проблему в будущем, вот некоторая дополнительная информация:

Для своего проекта я создал простой файл с достаточным количеством экспорта threejs, чтобы я мог скомпилировать мой проект. Он поставляется с аннотациями типов, которые были весьма полезны, поскольку позволяли компилятору замыкания проверять все типы и находить пару ошибок в моем коде. Я создал этот файл вручную. Я использую компилятор закрытия в основном для проверки ошибок, а для фактического минификации я использую менее мощный, но безопасный uglifyjs .

Кроме того, чтобы компилятор закрытия не переименовал мои символы общедоступного интерфейса, мне пришлось добавить несколько строк кода (эти четыре функции являются единственными общедоступными функциями моей библиотеки). Обратите внимание, что компилятор замыкания переименовывает все свойства, доступ к которым осуществляется через blah.xyz , но не затрагивает никакие свойства, доступ к которым осуществляется через blah["xyz"] .

Наконец, строка window['ColladaLoader2'] = ColladaLoader2 (еще раз обратите внимание на использование строки) была необходима, чтобы сообщить компилятору замыкания, что этот класс должен быть экспортирован в глобальную область видимости.

Но вы не используете закрытие для производства, а просто проверяете ошибки? я
не уверен, стоит ли тогда поддерживать внешний файл. Просто запустите закрытие
без агрессивных оптимизаций, и тогда вам не понадобится внешний файл
но вы по-прежнему получаете большую часть подтверждения, я полагаю, или, может быть, все
Проверка. Может можно уточнить?

Отправлено с телефона, извините за грамматику и лаконичность.
12 февраля 2013 г. в 5:19 «Роберт Карнеки» [email protected] написал:

Эта проблема какое-то время неактивна, но на случай, если кто-то захочет
Чтобы решить эту проблему в будущем, вот дополнительная информация:

Для своего проекта я создал простой файл https://github.com/crobi/ColladaAnimationCompress/blob/master/threejs-exports.js с достаточным объемом экспорта threejs, чтобы я мог скомпилировать мой проект. Это приходит
с аннотациями типов, что было весьма полезно, поскольку позволяло закрытие
компилятор, чтобы проверить все типы и найти пару ошибок в моем коде. у меня есть
создал этот файл вручную. Я использую компилятор закрытия в основном для ошибки
проверка, для фактического минификации я использую менее мощный, но безопасный
uglifyjs https://github.com/mishoo/UglifyJS.

Кроме того, чтобы компилятор закрытия не переименовал мой общедоступный интерфейс
символов, мне пришлось добавить несколько строк кода . Примечание
что компилятор закрытия переименовывает все свойства, доступ к которым осуществляется через blah.xyz,
но не затрагивает какие-либо свойства, доступ к которым осуществляется через blah ["xyz"].

Наконец, строка https://github.com/crobi/ColladaAnimationCompress/blob/366344d3aa5dbbc0a53c47a2c1759b86bb1e0fcd/ColladaLoader2.coffee#L3383 window ['ColladaLoader2']
= ColladaLoader2 (еще раз обратите внимание на использование строки) был необходим, чтобы сообщить
компилятор закрытия, что этот класс должен быть экспортирован в глобальную область видимости.

-
Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/mrdoob/three.js/issues/341#issuecomment -13426131.

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

Расширенный режим ведет себя как компилятор на строго типизированном языке (при условии, что информация о типе доступна): он предупреждает о неизвестных функциях или свойствах, предупреждает, если вы вызвали функцию с неправильным количеством аргументов или если вы использовали строковый параметр, где число было ожидаемым.

Например, простой режим преобразует следующий код

function fn() {
    var foo = {}; // local variable, safe to rename this
    foo.bar();    // undefined property, will crash here
}
fn();

без каких-либо предупреждений в

function fn(){({}).bar()}fn();

который, очевидно, выйдет из строя на ({}).bar() . Расширенный режим выводит следующий код

({}).a(); // fn() inlined, private member 'bar' renamed to 'a'

который по-прежнему вылетает, но компилятор также выдает предупреждение

Property bar never defined on foo at line 3 character 0.

• Обнаруженное закрытие ошибок относилось к типу ошибок, когда у меня была опечатка в имени функции или когда я передал один THREE.Vector3 в Matrix4.makeTranslation вместо трех отдельных чисел для компонентов x, y и z. .
• Если бы у меня было полное тестовое покрытие (чего у меня нет), я бы рано или поздно нашел эти ошибки. Однако иногда их трудно отладить, если они не проявляются сразу.
• Если threejs поставляет обновленный файл экспорта с каждым новым выпуском (огромные усилия для поддержки), компилятор закрытия улавливает все проблемы, возникающие из-за изменяющегося API (как это было в случае с Matrix4.makeTranslation ).
• Для меня настройка компилятора закрытия - слишком большая работа, так как для этого нужна среда выполнения java. Все остальные инструменты, необходимые для создания моей библиотеки, основаны на node / javascript.

В настоящее время я создаю файл externs.js своей библиотеки закрытия, чтобы интегрировать приложение THREE.js с библиотекой Closure. В основном мы пытаемся выяснить следующее:
Есть ли где-нибудь список всех классов THREE.js и методов-прототипов, которые они реализуют? Список должен быть примерно таким:

ТРИ Текстура
THREE.Texture.constructor
THREE.Texture.clone
ТРИ. Текстура. Утилизировать
THREE.DataTexture.clone

(и так далее...)

Ps- Three.js великолепен, но с правильными jsDocs этот список можно легко извлечь :)

У меня есть частичная реализация three.js экспорта здесь (написано вручную, поэтому может содержать некоторые ошибки).

@crobi : зачем вы добавили в него комментарии к документу? Похоже, это заняло довольно много времени, и я не уверен, что это необходимо ...

@taoeffect : комментарии в основном относятся к расширенному режиму компилятора закрытия. Мне нравится строго типизированный код.

@crobi , о, комментарии приводят к принудительному

Только если вы используете компилятор закрытия для проверки ошибок типа. Подобно машинописному тексту . Оба предварительно обрабатывают аннотированный javascript в простой javascript. Так что это только проверка во время компиляции.

Большинство комментариев о режиме расширенной оптимизации закрытия здесь неточны.

Чтобы решить основную проблему, вы можете использовать следующий инструмент для автоматической генерации закрывающих externs для любой библиотеки http://www.dotnetwise.com/Code/Externs/

Кроме того, если вы решите использовать three.js в качестве входных данных для вашего кода, а не просто использовать его как внешнюю библиотеку, вам нужно будет добавить флаг

--language_in=ECMASCRIPT5

Вы должны написать об этом сообщение в блоге, возможно, взяв перформанс
критический пример и посмотреть, запускается ли он через Google Closure
компилятор с хорошей оптимизацией имеет значение.
-Бен

В пн, 13 января 2014 г., в 12:31, Родриго Формигон <
[email protected]> написал:

Кроме того, если вы решите использовать three.js в качестве входных данных в свой код вместо
просто используя его как внешнюю библиотеку, вам нужно добавить флаг

--language_in = ECMASCRIPT5

-
Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/mrdoob/three.js/issues/341#issuecomment -32191167
.

С наилучшими пожеланиями,
Бен Хьюстон
Голосовой: 613-762-4113 Skype: ben.exocortex Twitter: @exocortexcom
http://Clara.io - Создание 3D-контента профессионального уровня на основе WebGL

Думаю, я мог бы написать такой пост. Тем не менее, чтобы прояснить, причина, по которой можно было бы запускать Three.js через закрытие (с файлом externs или без него), не обязательно только для оптимизации производительности. Замыкание в первую очередь предназначено для помощи в написании поддерживаемого кода на JavaScript (в частности, очень больших баз кода). Цель состоит в том, чтобы помочь разработчикам «приручить» JavaScript (написание собственного JS), а не «избегать» его (с помощью GWT или других подобных инструментов). Если вы просто попытаетесь скомпилировать Three.js как часть проекта Closure, компилятор может наорать на вас, потому что Three.js может не соответствовать некоторым из его стандартов (может быть, недостаточно JSDoc?). Использование флага компилятора --language_in решает эту проблему прямо сейчас, хотя вы получите несколько предупреждений. Если вы просто хотите скомпилировать свой собственный JS-код, но ссылаетесь на Three.js как на внешнюю библиотеку (таким образом, оставляя всю кодовую базу Three.js нетронутой и неоптимизированной), вам понадобится файл externs, упомянутый выше. Без файла externs Closure выдаст ошибки компиляции, говоря, что THREE. * Нигде не объявлено и т. Д.

Хотя я не могу написать сообщение в блоге, объясняющее, как и почему можно захотеть использовать Three.js в проекте Closure, вот лучшая вводная презентация об инструментах Google Closure, которые я видел: (Из Google I / O 2011) https://www.youtube.com/watch?v=M3uWx-fhjUc (я знаю, что это длинное видео, но действительно дает понять, какова цель компилятора и что на самом деле делают различные режимы компиляции. Он также описывает зачем вам нужен файл externs).

Привет, я с нетерпением жду возможности разработки приложения с использованием three.js и поэтому желаю поддержки опции ADVANCED_OPTIMIZATIONS.

Удаление мертвого кода хорошо работает, когда приложение для встраивания использует только часть функций Three.js.

В настоящее время для three.js требуется разработка каждой отдельной функции, потому что предполагаемое использование ограничивается фразой «Требуется только three.min.js!». Этот классический подход легко понять, но для кода, написанного с помощью этого подхода, минимизаторы JavaScript могут уменьшить код. size только за счет сокращения имен переменных (неэффективно для коротких имен переменных), удаления пробелов (эффективно только для пробелов с отступом, табуляции и разрывов строк) и других дешевых уловок.

Используя параметр ADVANCED_OPTIMIZATIONS в коде «Closure compiler style», он может удалить все «ненужные коды», которые в основном имеют значение для больших библиотек. Такие библиотеки, как Closure library, стали большими, но пользователей и разработчиков библиотек это не волнует, потому что они знают, что большая часть кода будет удалена на этапе компиляции.

Поскольку three.js уже написан в объектно-ориентированном стиле, я думаю, что (технически) несложно обновить весь код до кода «в стиле компилятора Closure». То, о чем я беспокоюсь ...

• Стиль компилятора закрытия требует аннотаций для каждой функции. На данный момент их нет. Сколько времени потребуется, чтобы добавить аннотации ко всем когда-либо разработанным функциям?
• Компилятор замыкания требует строгих определений типов. Даже для null и undefined вы должны работать с ними должным образом. Это может быть тяжелая работа для функций, которые имеют параметры "разрешено с нулевым значением", параметры "разрешено с неопределенным значением" и т. Д.
• Вам следует подготовить соответствующий файл externs, если вы с нетерпением ждете подготовки «библиотеки с полной версией», скомпилированной ADVANCED_OPTIMIZATIONS.

Хай Щедул Ксор,

Это хорошая идея. Не могли бы вы рассказать небольшой отрывок о том, как
это нужно добавить в three.js?

С уважением,

Рамсундхар Мадхаван

Во вторник, 24 июня 2014 г., в 16:23, Schedul Xor [email protected]
написал:

Привет, я с нетерпением жду возможности разработать приложение с использованием three.js и
поэтому желая поддержки опции ADVANCED_OPTIMIZATIONS.

Удаление мертвого кода эффективно работает, когда приложение для встраивания использует только
часть функций Three.js.

В настоящее время для three.js требуется разработка каждой отдельной функции, поскольку
предполагаемое использование ограничивается фразой «Требуется только three.min.js!». Этот классический
подход прост для понимания, но для кодов, написанных с помощью этого подхода,
Минимизаторы JavaScript могут уменьшить размер кода только за счет сокращения имен переменных.
(не действует для коротких имен переменных), удаление пробелов (эффективно только
для отступов, табуляции и разрывов строк) и другие дешевые уловки.

Используя параметр ADVANCED_OPTIMIZATIONS для "Closure compiler style"
кода, он может удалить все "ненужные коды", которые в основном
большие библиотеки. Библиотеки, такие как Closure library
https://developers.google.com/closure/library/ стал большим, но
пользователей и разработчиков библиотеки это не волнует, потому что они знают, что
большая часть кода будет удалена на этапе компиляции.

Поскольку three.js уже написан в объектно-ориентированном стиле, я думаю, что это
не (технически) сложно обновить весь код до "Closure compiler"
стилизованный код. То, что меня беспокоит ...

• Стиль компилятора закрытия требует аннотаций для каждой функции.
  На данный момент их нет. Сколько времени потребуется, чтобы добавить аннотации
  ко всем функциям когда-либо разрабатывались?
• Компилятор замыкания требует строгих определений типов. Даже для null и
  undefined, вы должны работать с ними должным образом. Это может быть тяжелая работа для
  функции, у которых есть параметры "null-allowed", "undefined-allowed"
  параметры, ...
• Вам следует подготовить соответствующий файл externs, если вы с нетерпением ждете
  для подготовки «полнофункциональной библиотеки», скомпилированной
  ADVANCED_OPTIMIZATIONS.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/mrdoob/three.js/issues/341#issuecomment -46957189.

@ schedul-xor нам определенно нужна помощь с этим ... действительно ли требуется анонтация кода или достаточно externs?

Привет,

Я новичок в этом сообществе, мне было бы интересно внести свой вклад в эти
изменения.

С уважением,

Рамсундхар Мадхаван

Во вторник, 24 июня 2014 г., в 19:23 г-н doob [email protected] написал:

@ schedul-xor https://github.com/schedul-xor нам определенно нужна помощь
с этим ... действительно ли требуется анонтация кода или этого достаточно с
экстерьеры?

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/mrdoob/three.js/issues/341#issuecomment -46973166.

Имейте в виду, что расширенная оптимизация требует определенного стиля кодирования, иначе она нарушит ваш код. Например, three.js смешивает uniforms["diffuse"] и uniforms.diffuse , что недопустимо при расширенной оптимизации закрытия. См. Также # 3222.

Добавление аннотаций строгого типа повсюду - это огромный объем работы и добавление большого количества строк комментариев (в моем проекте это увеличило количество строк в 2 раза).

Приятно иметь файлы externs для других веб-фреймворков / языков.

Согласно руководству , externs используются для защиты переменных, которые вы не хотите переименовывать. Это то, что вы используете, когда хотите защитить (в стиле компилятора без закрытия) сторонние библиотеки, используемые в проекте в стиле компилятора с закрытием, от агрессивного переименования переменных.

Я не уверен, будет ли компилятор по-прежнему пытаться вырезать мертвый код, даже если файл externs - единственное, что предоставляется. Будет намного проще, если вы будете писать только файл externs, а не писать аннотации ко всем функциям ...

Хотя, на мой взгляд, писать аннотации для каждой функции лучше, чем писать externs, потому что впоследствии станет трудно синхронизировать файл externs, если файл определения типа и исходный код отличаются. Вы можете себе представить, как это будет раздражать, если каждое исправление функции требует обновления файла externs. Любой выбор (externs или / ** * / комментарий к функциям) требует аннотации, в большинстве случаев побеждает более простой метод.

Поскольку three.js - большой проект, мне интересно, над чем мне в первую очередь следует поработать. Лучше начать с того, что можно легко сделать.

Как насчет размещения заголовков файлов, изменения стиля определения функции для каждой функции?

THREE.Material = function(){
  :
};
THREE.Material.prototype = {
    constructor: THREE.Material,
    setValues: function ( values1, value2 ) {}
    getValues: function () { return this.a; }
    :
};

↓

goog.provide('THREE.Material'); ← Write goog.provide('package.classname') at the first line

← three empty lines before <strong i="10">@constructor</strong>

/**
 * <strong i="11">@constructor</strong> ← Add <strong i="12">@constructor</strong> annotation to constructor
 */
THREE.Material = function(){
  :
};

← two empty lines before function definition
/**
 * <strong i="13">@param</strong> {!Array.<!string>} values1 Values1 explanation ← values1 is an array of strings. values1 can't be null, and elements inside values1 can't be null.
 * <strong i="14">@param</strong> {!number} value2 Value2 explanation ← value2 is a number.
 */
THREE.Material.prototype.setValue = function(values1, value2){
  goog.asserts.assertArray(values1);
  goog.asserts.assertNumber(value2);
  :
};


/**
 * <strong i="15">@return</strong> {!number} ← This function returns a non-null number.
 */
THREE.Material.prototype.getValue = function(){
  return this.a;
};

Будет проще ограничить все типы параметров и возвращать типы значений ненулевыми. Это значительно упростит передачу ошибок компиляции ADVANCED_OPTIMIZATIONS.

Хммм, я все еще не очень доволен множеством комментариев в коде. Иногда я задаюсь вопросом, не лучше ли было бы перенести все это на что-нибудь вроде TypeScript (жаль, что он принадлежит Microsoft).

Типскрипт лучше подходит для строго типизированного javascript, чем закрытие. Это мой опыт после того, как я переписал загрузчик коллада среднего размера сначала на javascript, совместимый с закрытием, а затем на машинописный текст. Оба подхода помогли найти ошибки во время компиляции. Closure выполнила несколько довольно хороших оптимизаций (встраивание, удаление мертвого кода) моего кода и поддерживает типы, допускающие значение NULL. С другой стороны, огромное количество комментариев отвлекало, а поддержка IDE (для автозавершения кода) была не такой хорошей, как с машинописным текстом. Кроме того, писать классы в машинописном тексте намного проще благодаря ключевому слову class похожему на ECMAScript6.

Но это только личное мнение. Что еще более важно, я хочу еще раз подчеркнуть тот факт, что вы должны убедиться, что все обращения к свойствам согласованы, прежде чем официально поддерживать закрытие в расширенном режиме компиляции. Наличие файла externs не помогает, доступ к свойствам должен быть согласованным для внутренних объектов, которые не экспортируются, поскольку вы _хотите_, чтобы они были агрессивно переименованы / встроены / удалены. Вы поймаете несогласованный доступ к свойствам, если аннотируете каждый класс и каждую переменную, но сделать это для всей кодовой базы three.js займет несколько недель (если я экстраполирую, сколько времени мне потребовалось, чтобы аннотировать мой проект).

Наконец, следует подробно обсудить перенос такого большого проекта, как three.js, на любой другой язык / фреймворк / стиль кодирования.

Хорошо, я согласен, что three.js огромен, поэтому добавление аннотаций к каждой функции может занять несколько недель. Могут существовать лучшие AltJS, чем закрытие. Это необходимо обсудить (если вы с нетерпением ждете возможности переноса на что-то другое) более подробно.

Извини не могу дождаться. Я разветвляю текущий коммит и приступаю к портированию.

Привет,

Можно ли автоматизировать добавление этой аннотации? Если да, то можем добавить
to build.py и добавить непосредственно перед включением расширенной оптимизации закрытия.

С уважением,

Рамсундхар Мадхаван

В среду, 25 июня 2014 г., в 6:05, Schedul Xor [email protected]
написал:

Хорошо, я согласен, что three.js огромен, поэтому добавляю аннотации к каждому
функции могут занять несколько недель. Могут существовать лучшие AltJS, чем
закрытие. Это необходимо обсудить (если вы хотите перенести его на
что-то еще) глубже.

Извини не могу дождаться. Я разветвляю текущий коммит и приступаю к портированию.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/mrdoob/three.js/issues/341#issuecomment -47047966.

@ ramsundhar20 , на мой взгляд, добавление аннотаций (неточных? лучше, чем ничего. не большая проблема. их можно обновить) значительно упростит автоматизацию.

В настоящее время Three.js содержит 163 файла javascript с определенными 1354 функциями. Да, он огромен, но это не такая уж далекая цель.

// Боюсь, если эта тема не к месту ...

@ schedul-xor еще раз, я не очень люблю комментировать каждую функцию: /

@mrdoob Хорошо, я понял.

Уважая вашу политику, я хотел бы добавлять комментарии для каждой функции только в моей вилке. Кроме того, я никогда не буду делать запросы на вытягивание. Вместо этого я перенесу оригинальные модификации three.js в свою вилку в стиле замыкания. Будем признательны за ваше благосклонное внимание.

Это звучит неплохо :)

Спасибо! Я начну над этим работать.

Есть ли хотя бы базовый файл externs three.js для использования с закрывающим компилятором? Для этого не требуется, чтобы в исходном коде Three.js были какие-либо дополнительные аннотации в стиле Google, это просто для того, чтобы сделать ссылку из внешнего app.js, которое использует three.js достаточно компилируемым / запутанным?

Меня также очень интересует качественный, полный файл externs для three.js. Вот один, но не полный:

https://github.com/cljsjs/packages/blob/master/three/resources/cljsjs/three/common/three.ext.js

Я полагаю, что можно начать с этого и вручную добавить то, что вы используете.

Да, посчитайте мой голос. Идеально для компилируемого расширенного режима, 100% типизированного threejs - или, по крайней мере, файла externs.

Выведение типов стало лучше, а требуемый беспорядок стал меньше. При наличии областей видимости и псевдонимов код не должен быть таким подробным, как библиотека закрытия. Это в значительной степени сводится к написанию типизированных встроенных документов в случае чистого кода. Достаточно ли этого, чтобы перевесить все преимущества?

Сверхагрессивные настройки, то есть расширенный режим + сжатие JS + оптимизация на основе типов, не только удаляют мертвый код, но и могут делать все классные вещи, которые может делать оптимизирующий компилятор:

Именованные константы / перечисления будут заменены цифрами. Кроме того, компилятор может отслеживать константу, выполнять вычисления с другими константами и, наконец, вставлять простое число там, где это необходимо. Конечно, зависимое управление потоком подвергается устранению мертвого кода. Функции, которые имеют только один активный сайт вызова в результирующем приложении и те, чья сжатая форма будет меньше, чем их определение, будут сохранены встроенными. Пространства имен удалены. Все незащищенные имена сокращены до минимума.

Поиск в JavaScript сравнительно дорого обходится. Комбинация переименования, сворачивания констант и встраивания избавит от множества поисков и многочисленных вызовов функций. Вдобавок к этому, учитывая соответствующий заголовок (он есть в библиотеке закрытия), все стандартизованные константы WebGL могут быть запечены в рендерере.

В результате мы получаем более компактную, быструю, самодокументирующуюся и автоматически настраиваемую библиотеку. Компилятор также обнаружит намного больше ошибок при более агрессивных настройках - это, вероятно, упростит проверку кода. И последнее, но не менее важное: есть эффект запутывания: объединение клиентского кода с настроенной библиотекой обеспечивает гораздо лучшую защиту от кражи интеллектуальной собственности, чем код с открывающими символами, которые были сохранены с помощью файла externs.

Не могу найти указанную выше ветку. Кто-нибудь еще работает над типизированной версией?

@mrdoob Есть ли надежда на изменение

Буду рад помочь.

@mrdoob Есть ли надежда на изменение

На данный момент я занимаюсь рефакторингом WebGLRenderer 😇

Можно изменить константы на const а не на var имеет хорошую поддержку для всех браузеров WebGL https://kangax.github.io/compat-table/es6/ (const-> basic) и js движки начинают оптимизацию для const Ускорение глобальных констант с помощью оптимизации с фиксированным полем

Однако интересно, поскольку он работает только вместо var , применим только к очень небольшой части случаев, о которых я говорю, - даже когда речь идет только о константах. Кроме того, JIT-компиляторы по определению спешат, поэтому они, естественно, не могут конкурировать с оптимизацией всей программы, выполняемой автономным инструментом. Каждый JS-движок должен уважать структуру кода и не может произвольно его рефакторировать, поскольку мы ожидаем, что сможем, например, открыть консоль и найти программу, которую мы в нее вставили, заменить определенную функцию и т. Д.

Вернемся к завершению поддержки компилятора: я немного почитал и поэкспериментировал. Вот что я выяснил:

• Для работы в расширенном режиме аннотации не требуются,
• аннотации можно добавлять постепенно, чтобы повысить уровень оптимизации, и
• загрузчику нужно немного заботиться, чтобы он продолжал работать, но это довольно просто.

Есть три основных варианта использования:

1. Модели можно сжимать вместе с приложением и библиотекой.
2. Приложение и библиотека сжаты. Модели загружаются во время выполнения.
3. Библиотека скомпилирована в базовом режиме, и приложение в расширенном режиме хочет ее использовать.

Третий требует файла externs для всех Three.js и требует много работы для слишком маленькой выгоды IMO. Поэтому я остановлюсь только на первых двух - в любом случае, это предпочтительные:

Когда компилятор видит

anObject['aProperty']

он не коснется имени свойства (никакие строки никогда не меняются).

anObject.aProperty

с другой стороны, позволяет компилятору последовательно переименовывать свойство, если он не знает, что anObject является внешним по отношению к компилируемому приложению. Компилятор знает об этом из встроенного или явно предоставленного _externs_.

Вот рецепт:

• Мы делаем так, чтобы загрузчик последовательно обращался к свойствам, используя точечную нотацию.
• Мы вводим ввод и пишем файл externs только для JSON .
• Компиляция с использованием этого файла externs должна быть всем, что нужно для работы варианта использования 2.
• Для варианта использования 1 мы не используем файл externs, а вместо этого удаляем кавычки из ключей объекта в JSON:

{
    "camera": {
        "object": {
    // ...

просто стал бы

{
    camera: {
        object: {
    // ...

Довольно просто, не правда ли?

Вариант использования 1 становится еще более привлекательным, когда формат JSON позволяет использовать внешние двоичные данные (сырые или сжатые через webgl-loader или o3dgc) - технически еще одна функция, полностью ортогональная поддержке закрытия.

Файл externs также может заменить устаревшие страницы Wiki, документирующие формат файла :-).

Я знаю, что этот вопрос уже давно закрыт. Однако недавно у меня была такая же проблема с использованием three.js в проекте компилятора закрытия, и я попал на эту страницу. Я написал инструмент, который преобразует .d.ts (файлы объявлений машинописного текста) в файл компилятора закрытия. Используя этот инструмент и замечательный описанный файл дескриптора DefinitoTyped / threejs, он отлично работает.
Инструмент: https://github.com/eredo/tsd2cce или установите через npm install -g tsd2cce

Надеюсь это поможет...

@eredo, который меня полностью выручил. Во всех других генераторах, которые я пробовал, отсутствовало большое количество определений методов для библиотеки three.js. Спасибо!

@eredo @Corkle или кто-нибудь еще, не могли бы вы показать нам, как использовать tsd2cce ? Первый аргумент явно является файлом определения .d.ts, но каков второй аргумент? Я получаю эту проблему. https://github.com/eredo/tsd2cce/issues/6

На самом деле я обнаружил, что использование r73 d.ts с февраля отлично работает с tsd2cce, хотя r73 для меня слишком стар.

Правильный способ сделать это сейчас - использовать tsickle для генерации из файлов d.ts.

Всем привет,

Для потомков и всеобщего блага я решил сообщить здесь о своих собственных попытках еще больше сжать библиотеку с помощью ADVANCED_OPTIMIZATIONS компилятора Google Closure Compiler и некоторых других настроек.

Я создал extern.js, который позволяет Three.min.js с включенной расширенной оптимизацией. Это ДАЛЕКО от совершенства.

Чтобы создать его, я начал с extern.js на основе предыдущих примеров в этом потоке. При такой компиляции библиотека была повреждена из-за искаженных свойств, не включенных в этот внешний файл. Используя параметр --property_renaming_report в компиляторе закрытия, я получил полный список искаженных свойств. После добавления ВСЕХ этих свойств в extern.js свойства больше не искажались, и вывод был таким же, как SIMPLE_OPTIMIZATIONS. Оттуда я выборочно / вручную начал комментировать разделы extern.js и подтверждать, что библиотека по-прежнему работает в минифицированной форме.

Мне бы очень понравилось автоматизировать это предположение и проверку и получить идеальный extern.js, который безопасно искажает как можно больше имен свойств. У меня была идея использовать модульные тесты для THREE.JS и программно определять, какие искаженные имена свойств привели к неудачным тестам, но в настоящее время не представляется возможным запускать модульные тесты из командной строки, например, с помощью phantomjs. (Наверное, из-за WebGL)?

В любом случае это «прогресс» к уменьшению минифицированной библиотеки, помогающей мне уменьшить общий размер JavaScript-кода SPA.

externs.js

обновлена ​​команда package.json build-closure

Я также использовал команды замены строки, чтобы удалить все сообщения console.warn и console.error из библиотеки, как вы можете видеть в команде build-closure. С помощью этого, а также комментируя определенные разделы кода, я сократил минимизированную библиотеку примерно на 20%, и есть возможности для улучшения.

@mrdoob Выполняя здесь что-то вроде моего метода, вы могли бы в конечном итоге предоставить extern.js, который позволяет ADVANCED_OPTIMIZATIONS, не загромождая код аннотациями, специфичными для этого компилятора, что, по-видимому, было вашей основной заботой.

@ medmr1 Замечательно ! Вы пробовали скомпилировать свое приложение с библиотекой three.js в одном флаконе? В идеале это избавило бы от необходимости во внешнем файле.

Я не пробовал строить все в рамках замыкания, нет. Это может сработать, но я подозреваю, что все еще будут проблемы с изменением некоторых свойств, упомянутых программно? IE такие вещи, как var thing = ShaderLib[ shaderType + "BumpMapFrag"] Но, может быть, я избавлю себя от множества проблем?

Да, что-то вроде var thing = ShaderLib[ shaderType + "BumpMapFrag"] сломается при расширенной оптимизации. ссылки на свойства должны быть статически анализируемыми. Вы можете сделать что-то вроде:

function(shaderType) {
  if (shaderType == "a") {
    return ShaderLib.aBumpMapFrag;
  }
  if (shaderType == "b") {
    return ShaderLib.bBumpMapFrag;
  }
...

Создание правильного файла externs определенно более выгодно для проекта в целом, поскольку большинство людей не будут компилировать свое приложение с помощью Closure Compiler, а будут использовать только опубликованную минифицированную версию.

Вместо externs вы также можете попробовать аннотацию @export .
https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#export -export-sometype