Комментарии 9
В "-vs-binding" мы указали, что Visual Studio должна вызывать задачу "webpack-script" (Которую студия теперь видит, благодаря установленному расширению) каждый раз перед построением проекта.
Это, вообще говоря, очень не хорошо, ибо вы таким образом сборку прибиваете к студии и к наличию установленного в ней расширения. Лучше в файл проекта добавить target:
<Target Name="AfterBuild">
<Exec Command="npm run webpack-script" />
</Target>См. более полный пример.
У Вас вебпак первый или второй?
Для сборки можно еще установить webpack глобально и запустить отдельно в консоли с ключем w и тогда он будет сам смотреть за изменением файлов и собирать сразу. webpack -w
Для asp.net core есть https://github.com/aspnet/JavaScriptServices, который предоставляет:
А сгенерировать проект со всем этим добром, настроенным webpack и т.д. можно через их генератор:
- сборку webpack в памяти при разработке (чтобы не надо было пересобирать или ставить watch),
- добавляет поддержку hot module replacement для angular и некоторых других библиотек,
- добавляет рендеринг на стороне сервера
- и прочие плюшки.
А сгенерировать проект со всем этим добром, настроенным webpack и т.д. можно через их генератор:
npm install -g yo generator-aspnetcore-spa
yo aspnetcore-spa
Typescript удобнее отлаживать в студии? Всегда думал что лучше дебажить js в браузере.
Разве не удобнее разнести вообще фронт и бэкенд как разные проекты? Бэкенд отдает чисто данные по бизнес логике, фронт роутит и наполняет контентом странички — или с typescript такое не прокатит и надо тащить еще фреймворк (angular, react)?
Так всегда проще нанять чистого фронта, которому привычнее работать через webstorm, sublime и тд чем через Vs.
Еще раз, я ничего не знаю про веб. Но в случае с C++ например мне сложно представить кого-то, кому удобнее ковыряться в отладчике уровня ассемблера вместо отладки по исходникам в ide. Про разнос на 2 проекта — можно и разнести наверно, но зачем? Тут цель сделать минимально возможный по зависимостям и общей сложности проект, чтобы с него делать эксперименты с вебом (конкретно у меня это для обучения вебу в принципе). А вообще фронтендеру и так и так придется работать с .cshtml, ну а билдить проект он может и через командную строку через msbuild если студия так не нравится. И работать в своем блокноте сколько влезет.
>например мне сложно представить кого-то, кому удобнее ковыряться в отладчике уровня ассемблера вместо отладки по исходникам в ide.
Если есть source map то бегать по исходникам вы будете в самом броузере. Ну а dev tools хрома имхо побогаче будут чем средства ide, универсально (ide много, броузеров мало) ну и вообще во фронт-энде так принято ) Да, про линтер забыли (tslint), без него плохо.
За статью — огромное спасибо, я далеко не новичок в мире ноды и фронт-энда, но никакого представления о .NET не имею, сейчас встал вопрос быстрого погружения — очень пригодилось.
Если есть source map то бегать по исходникам вы будете в самом броузере. Ну а dev tools хрома имхо побогаче будут чем средства ide, универсально (ide много, броузеров мало) ну и вообще во фронт-энде так принято ) Да, про линтер забыли (tslint), без него плохо.
За статью — огромное спасибо, я далеко не новичок в мире ноды и фронт-энда, но никакого представления о .NET не имею, сейчас встал вопрос быстрого погружения — очень пригодилось.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание минимального ASP.NET Core веб-приложения с поддержкой npm, Webpack и TypeScript в Visual Studio 2017