А на что там место тратится?
Можно ж просто удалять папку node_modules и прочее сгенерированное в старых примерах.
Я не знаю. Webpack требует 100 МБайт, а Gulp требует, тоже около 100 МБайт. Ты можете попробовать сами написать “Hello, World” приложение на TypeScript с использованием Gulp по инструкции: https://www.typescriptlang.org/docs/handbook/gulp.html У вас займёт это приложение около 100 МБайт.
Выбранный мною способ требует меньше 1 МБайта. Я TypeScript компилятор, Browserify и UglifyJS. Я много времени потратил на Webpack и Gulp и понял, что намного проще начинающему разобраться с выбранным мною способом. Особенно это проявляется когда начинающих захочет ставить точки останова в TS-коде unit-тестов в среде разработки, например VSCode. Я знаю, как выбранным мною способом отлаживать unit-тесты на TypeScript на клиенте, сервере и в коде, который используется и клиентом и сервером (shared code). Знаю как эти unit тесты на клиенте собирать в bundle и делать маленький размер. У меня не всё получилось из перечисленного на Webpack и Gulp. Я не хочу терять на них время. Тем более, что один пример занимает около 100 МБайт, а чтобы чему-то научиться нужно писать сотни и сотни примеров: маленьких и средних. Если у кого-то появится желание переводить примеры данной книги на Webpack и Gulp, то создавайте отдельные темы. Я свой выбор сделал и выбранные мною инструменты устраивают меня на 100%. Очень важно ещё для меня, что благодаря компиляции в асинхронные модули и RequireJS я могу публиковать примеры из нескольких TypeScript файлов (а так же unit-тесты на TS и Jasmine) в песочнице Plunker. Я считаю, что это лучшая песочница для TypeScript на сегодня, где можно публиковать многофайловые примеры.
Я долго думал, публиковать ли эту фразу или умолчать и сэкономить время и силы на попытку объяснить свой выбор и не устраивать холивар любителей Gulp и противников Webpack или наоборот. Моя позиция выстрадана борьбой с этими инструментами. Моя борьба длилась больше года. Очень много драгоценного времени я потерял в попытке настроить эти инструменты для полного охвата, того что мне нужно от них. Я так и не смог с ними до конца разобраться. Я выбрал, то что выбрал и больше не хочу тратить время на попытки приручить эти инструменты для TypeScript. Драгоценного времени очень мало. Его нужно тратить на создание множества примеров для оттачивания знаний и навыков, которые бы занимали мало места на ноутбуке, которые бы легко было объяснить и которые бы позволяли публиковать примеры в песочницах.
ну так это один раз если ставить глобально, а если в проект, то можно
Да, в мире JS одна из проблем, что все инструменты постоянно меняются, и что есть не менее 3 популярных аналогов (WebPack, Gulp, Grunt, …, еще например всякие обертки типа Laravel Mix) даже для одной этой задачи.
Это первое что приходило мне во голову больше года назад. Но я, наверное, недостаточно умён для этих инструментов. У меня то тут, то там возникали проблемы с проблемы при работе с этими инструментами и TypeScript модулями. Одно из самых главных, что RequireJS позволяет публиковать многофайловый TS-пример в песочнице Plunker. Мне очень важно при написании уроков для начинающих показывать пример в работающем виде в песочнице. Огромная ошибка начинающих в том, что они закапываются в технические детали работы инструментов, но не создают множество примеров. Важно быстро запускать примеры на своём компьютере и располагать их в песочнице для вопросов и ответов. Я предпочитаю, чтобы я мог быстро запустить любой пример и не ждать, что установится Webpack, а наиболее важно - это взаимодействие с начинающим через песочницу, где классы TypeScript удобно расположены в отдельных файлах, а я могу быстро перекопировать свой пример с компьютера в песочницу, начинающий может поменять, что-то в примере, прислать мне ссылку, я могу что-то подправить. Либо начинающий быстро перекидывает свой пример в песочницу. В развитии, очень важно уметь быстро располагать unit-тесты в песочнице, так как я могу создать unit-тест, дать ссылку и показать, что такой-то unit-тест обнаруживает проблему в функционале алгоритма.
Далеко не все меняются. Например, Browserify, UglifyJS и RequireJS не меняются долгие годы. TypeScript позволяет компилировать, как в CommonJS модули, что подходит для релиз, так и в AMD модули, что подходит для RequireJS и для публикации много файловых TypeScript примеров в песочницах, что очень важно для начинающих.
Этот вариант мне категорически не подходит. Я писал почему. Может не все причины указал. Если я активно работаю с фреймворками Phaser, Babylon.js, пишу примеры на чистом WebGL, с базой данных MySQL, веб-сокетами, свои примеры с сайтами на Node.js/TS, множество разных других примеров и начатых проектов. У меня должно быть множество примеров в наличие. Я не хочу каждый раз ждать, когда они скачаются. Тем более, публиковать многофайловый пример невозможно на Plunker и Unit-тесты там на TypeScript не опубликуешь без AMD-модулей и RequireJS. Я этот инструмент освоил и не нужно уговаривать меня переходить на Webpack, Gulp и Grunt. Меня выбранные мною инструменты устраивают, как для демонстрации примеров ученикам в песочницах, так и для собственных разработок.
Этот вариант мне ещё не подходит потому что я активно практикуюсь, осваиваю и использую Time Management: Getting Things Done. Я использую его вместе с Trello.com Этот метод подразумевает быстрое переключение между проектами для выполнения следующих шагов, которые могут занимать меньше двух минут. Я могу переключаться между десятками примеров и проектов, отмечая сделанный шаг, описывая следующие шаги. Я не могу жать скачивания пакетов.
Давайте не будем продолжать тему с выбором инструментов. Я на автомате освоил данный стек инструментов. У меня совершенно нет времени и желания осваивать другие инструменты. Есть гораздо более важное дело - это освоить базовый API фреймворка/движка Babylon.js и постепенно через эксперименты, примеры, проекты, туториалы и т.д. углубляться в этот API, делать его частью своей повседневной работы и жизни.
У npm вроде есть кэш, так что должно быть быстро если примерно одни и те же пакеты.
Да я не любитель, меня больше причина удивила )
Я считаю, что место на диске - не то, на что стоит тратить время в 2019 году.
За несколько тысяч рублей можно купить SSD на пару сотен ГБ (стандартный SATA или m.2 SATA, не NVMe).
За 8-10 т.р. - 1 ТБ, и надолго забыть про это. Ну если не коллекционировать фильмы в максимальном качестве и не ставить несколько AAA игр сразу (всякие Call of Duty уже больше 100 ГБ занимают).
Я подробно постарался описать большинство главных причин, почему я отказался от Webpack и Gulp в пользу:
- Require/AMD - для отладки TS-файлов в VSCode по шагам и для расположения примеров с несколькими TS-файлами в песочнице
- Browserify/UglifyJS - для сборки в Release
Webpack и Gulp не позволяют мне располагать мои примеры из нескольких TS-файлов в песочнице Plunker, как это сделано в примерах:
- Инструкция, как расположить несколько классов на TypeScript в песочнице Plunker
- Инструкция, как подключить стороннюю библиотеку к своему примеру на TypeScript в песочнице Plunker
- Запуск unit-тестов в песочнице и локально на TypeScript и Jasmine
Я выше писал, что мне очень важно иметь возможность запускать unit-тесты в песочнице и я не знаю, как это сделать на Webpack и Gulp. Я знаю, как это сделать на RequireJS. Я знаю, как быстро можно скопировать свой пример на Plunker и своего проекта.
Я не знаю, что ещё сказать в своё оправдание. Моих мозгов реально не хватило, чтобы разобраться до конца в Webpack и Gulp. Не отличаюсь я сильными мозгами. А вот разобраться с Browserify, Uglify и RequireJS - у меня хватило мозгов - очень быстро я разобрался. Меня очень сильно обрадовало, что как бонус - занимает мало места. Я правда, не смогу справится с Webpack и Gulp, чтобы расположить примеры в песочнице, я не смогу разобраться, как глобально их использовать, потому что я пробовал и возникли проблемы. Не могу я сейчас от того, что я отработал до автоматизма, а именно: Browserify, Uglify и RequireJS. Я уже столько сотен примеров на них сделал, что я закрытыми глазами могу написать проект с их использованием. Я не могу это бросить в пользу опять начинать изучать Webpack и Gulp. У меня даже многочасовые видео курсы лежат по Webpack и Gulp и есть книги по ним. Но я уже владею инструментами, которые позволяют:
- отлаживать TS-код пошагам в VSCode
- собирать в релиз, то есть в маленький bundle.min.js
- публиковать пример из нескольких файлов на Plunker
- собирать unit-тесты на клиенте в Debug и Release
Я сейчас проверил @types/requirejs занимает всего 20 КБайт. Это всё, что мне нужно, потому что для require.min.js я подключаю через CDN. А Browserify и UglifyJS я установил глобально.
Я не вижу никаких причин возвращаться к разбирательству, как сделать полноценный процесс разработки на Webpack и Gulp. Я не знаю, как ещё объяснить свой выбор. Для мен наиболее важно то, что я могу располагать многофайловые примеры и примеры unit-тестов на Plunker. Мне лично - это очень нужно. Я учусь инжектировать зависимости, которые созданы через интерфейсы на Jasmine (в TS есть interface, как в C#). Это наиболее важная вещь для практических примеров - то есть замена инжектированных зависимостей на Mock-объекты. Как вариант, этой практике нужно посвятить время, а не доводить до автоматизма Webpack и Gulp, когда я уже довёл Browserify, Uglify и RequireJS
Так я ж не говорил, что это плохой выбор и что надо о чем-то спорить. Просто уточнил один момент и объяснил почему изначально спросил )
Это индивидуально очень: как кто относится к занимаемой памяти и к выбору инструментов, как к выбору языков, какие у кого требования и финансовые возможности. У одного 20 ТБайт и он делает кучу сборок разных своих экспериментов с CryEngine5, где одна сборка занимает 6 ГБайт. Для него - 10 ГБайт - это копейки, особенно если у него нет игр и HD фильмов. Просто получается выбор либо пример на TypeScript весит 20 КБайт, либо 100 МБайт. Я очень часто бегаю по папкам в Far Manager. То один проект запущу, в нём что-то попробую, то другой. Студенты на форумах спрашивают. Хочется у себя запустить с точками останова и сразу в песочницу закинуть пример из нескольких файлов. Все проекты требуют только 20 КБайт дополнительной памяти. У меня в каждом проекте есть файл RequireConfig.ts:
requirejs.config({
baseUrl: "."
});
requirejs(["Program"], (Program) => { });
Его нужно в песочницу скопировать и тогда проект из нескольких файлов запустится в песочнице. Оно одно с другим связано. Тот же RequireConfig.ts я использую на выставления точек останова и отладки по шагам прямо в VSCode. Так как у меня на ноутбуке 300 ГБайт, из которых 80 - это для диска “C” для системы и программ, а второй на 220 ГБайт, где почти всё забито видео курсами на английском и книгами на английском (с примерами, которые иногда весят по 100 МБайт и даже 1ГБайт). Честно скажу, я не готов потратить 10 тысяч, потому что у меня больше 20 ГБайт свободного места на жёстком! Тем более, что, как я объяснял у меня связь песочницы и отладки. Если только папку с примерами на Babylon.js приходится иногда чистить, потому что модуль занимает 24 МБайт, а модуль Phaser вообще занимает 45 МБайт - тоже чищу, но на Phaser я пока может десяток примеров запускал. Но у меня основное направление для работы сейчас - это чистый WebGL (glMatrix весит 665 КБайт) и C#/OpenTk (где папка bin может весит 35 МБайт, которую я стараюсь удалять часто). Бывает у меня большая чистка, когда я запускаю рекурсивное удаление папок на пару десятков минут, если накопится много: FOR /d /r . %d IN (bin) DO @IF EXIST "%d" rd /s /q "%d"