LINUX.ORG.RU

Хочу пакетный менеджер js/css в НЕ жавоскриптовый проект

 ,


1

1

Как я хочу: в проект кладётся конфигурационный файл. В конфигурационном файле пишется целевая директория и названия зависимостей с их версиями. Нажимается install и оно устанавливает зависимости в целевую директорию. И, блджад, всё.

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

Смотрю сейчас bower.io, а он мне пишет «we recommend yarn and webpack for new front-end projects!» Но я-то не хочу делать фронтенд-проект, я хочу писать фронтенд вместе с бекендом.

Или в современной веб-разработке без конпеляния css в ecma42 бабелем жизни уже совсем нет?


Напиши тогда свой на Python, если js тебе не по вкусу.

th3m3 ★★★★★ ()
Ответ на: комментарий от th3m3

Мне пофиг на чём оно написано. Я просто хочу, чтобы оно поставило бутстрап в static/ и подтянуло туда же jquery как зависимость.

suuaq ()

Это вебдев, наслаждайся

anonymous ()
Ответ на: комментарий от suuaq

Bootstrap и jquery, уже прошлый век. Проблему можно решить переходом на более современные решения ;)

th3m3 ★★★★★ ()
Ответ на: комментарий от th3m3

Я заглянул в этот огород. Даже в чёртовых крестах можно написать g++ file.cpp и оно будет работать. А в этих ваших современных решениях тулчейн переусложнили настолько, что надо готовые бойлерплейты качать, потому что сам замаешься его конфигурировать. Найух такое, сначала сделайте нормальную инфраструктуру.

suuaq ()
Ответ на: комментарий от suuaq

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

Есть вариант запрыгнуть в постоянно уходящий поезд и быстро войти в положение дел, можно начать изучать Vue.js. Никаких проблем с освоением, как с react и angular. Vue просто можно взять и использовать. Предварительно заглянув в документацию, а она и на русском есть https://ru.vuejs.org/v2/guide/ Можно даже как jquery подключить, без всяких сборщиков. При этом, он будет быстрее Angular и React, имеет в себе многие их плюшки и своих не мало. В общем, идеальный вариант на данный момент.

th3m3 ★★★★★ ()
Ответ на: комментарий от th3m3

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

А которые из них мне нужны?

Есть вариант запрыгнуть в постоянно уходящий поезд и быстро войти в положение дел, можно начать изучать Vue.js.

Ну хорошо, ну хорошо. А кто с этой хренью вместо меня будет писать стили? Как мне её воткнуть в flask? А если пользователь врубит noscript, оно как будет работать?

suuaq ()
Ответ на: комментарий от suuaq

А которые из них мне нужны?

Понятия не имею :) Но, что-то уже могло устареть, что уже можно заменить современными фичами.

А кто с этой хренью вместо меня будет писать стили?

Никто.

Как мне её воткнуть в flask?

Можно как и jquery - прописать в коде html. И это один из вариантов.

А если пользователь врубит noscript, оно как будет работать?

Может ещё поддержка IE 6 нужна? :)

th3m3 ★★★★★ ()
Ответ на: комментарий от th3m3

То есть ты мне предлогаешь вместо «хуяк за два часа на коленке и оно работает» выучить какой-то левый фреймворк, научиться прилично в дизайн, забить на часть пользователей и даже не знаешь, зачем оно мне надо? Чувак, у тебя реальная проблема с логикой.

suuaq ()
Ответ на: комментарий от suuaq

Если надо хренак, хренак и в продакшен. То тоже можно использовать современный подход. ES5, ES6+. Фигачить на vanilla js, без всякой jQuery. jQuery по большей части, была нужна для поддержки браузеров, сейчас это уже неактуально. Бутстрап - всем нужна была его сетка, сейчас есть flexbox и css grid. CSS Grid - сам как фрамеворк.

th3m3 ★★★★★ ()
Ответ на: комментарий от Shadow

Что-то оно тоже какое-то переусложнённое и хочет в проект интегрироваться зачем-то.

А я хочу, чтобы как pip install -r textfile-with-dependencies

suuaq ()
Ответ на: комментарий от th3m3

ES5, ES6+

В браузер нативную поддержку завезли?

Фигачить на vanilla js, без всякой jQuery.

Вообще без проблем.

Бутстрап - всем нужна была его сетка,

Мне пофиг, чего там кто хотел, а я его компоненты использую и свои рисовать не намерен.

suuaq ()

Как я хочу: в проект кладётся конфигурационный файл. В конфигурационном файле пишется целевая директория и названия зависимостей с их версиями. Нажимается install и оно устанавливает зависимости в целевую директорию. И, блджад, всё.

Можно простейший Makefile написать, не конфигурационный файл, конечно, но всё это сделать - на раз-два.

pod ★★ ()

Я немного не понял, а чем не нравится вариант с webpack? Ставишь пакеты, вебпак помещает твои ассеты в нужную директорию(при этом можешь минифицировать и хеш добавить).
Это просто типичный сценарий использования, с минимальным изучением доков(считай quick start).

ritsufag ★★★★★ ()
Ответ на: комментарий от suuaq

Да ладно, две строчки на питоне дописать! Одну - список скриптов с компиляторами, другую - список css. Дальше фласк сам пересобирать при необходимости будет.

Shadow ★★★★★ ()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от th3m3

Фигачить на vanilla js, без всякой jQuery

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

anonymous_sama ★★★★★ ()
Ответ на: комментарий от th3m3

нормал так, чё. человек спрашивает, как ему зависимости подтягивать в static, а ты ему «а вы верите в бога? примкните к нашей церкви и забудьте о проблемах!»...

ТС, если найдешь такое удобное решение - напиши сюда, ябы тоже не отказался. оно вроде мне не припекает настолько, чтоб свое писать, но если бы было - былоб удобно. особенно если позволяло бы прописывать туда и свои репы, вообщеб цены небыло.

genryRar ★★ ()

Ну так возьми и напиши копирование своего бутстрапа и jquery из node_modules куда надо в своём package.json (в build, например). И npm, и yarn это умеют.

Единственный момент с этими npm scripts — это windows: если хочешь, чтобы твой пакет ещё и там можно было собрать, то нужно пользовать только то, что и в cmd.exe сработает. Но и для этого есть пакеты.

x3al ★★★★★ ()
Последнее исправление: x3al (всего исправлений: 1)
Ответ на: комментарий от ritsufag

Я немного не понял, а чем не нравится вариант с webpack?

А это вариант? Читаю мануал, оно мне начинает втирать про точку входа и лоадеры. Как точку входа мне ему wsgi.py указывать что ли? Или каждый темплейт по отдельности? И нафига мне ещё какие-то лоадеры? Переусложнённая фигня в общем.

suuaq ()
Ответ на: комментарий от x3al

Ну правда, можно же на баше скрипт забабахать в 10 раз быстрее и с тем же результатом. И не нужно разбираться с нодой и её заморочками.

suuaq ()
Ответ на: комментарий от suuaq

Ну так bash-скрипт ты и пишешь внутри scripts: в этом package.json. Однострочники обычно прямо внутри него и пишутся.

x3al ★★★★★ ()

....

Я не уверен конечно, но можно например устанавливать зависимости через npm, а собирать при помощи https://github.com/nodeca/mincer. В src файлах прописывается «The Directive Processor» node_modules/pat_to_main_file, затем mincer cli собирает все это дело.

anonymous ()
Ответ на: .... от anonymous

На какой чёрт нужно лишнюю зависимость там, где достаточно написать буквально cp двух файлов, если это прекрасно работает как npm-скрипт?

x3al ★★★★★ ()
Ответ на: комментарий от x3al

Допустим нужно подключать зависимости в определенном порядке и собирать все в 1 файл, можно наверное и на баше заскриптить, но удобнее видеть что и как подключается (директивы) + есть поддержка пре / пост процессоров и sourcemaps (я про mincer).

anonymous ()
Ответ на: комментарий от suuaq

Карочи ясно. Не осилил даже quick start, а потом эти макаки лезут в веб со своими велосипедами.

ritsufag ★★★★★ ()

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

ТС просил указать на простое не перекачанное решение, которому не нужны сотни зависимостей и прочего буллшита. Зачем его тянуть в секту, попутно принижая его желание не усложнять то, что можно не усложнять?

deep-purple ★★★★★ ()
Ответ на: комментарий от anonymous_sama

Вот именно из-за такого подхода (ради пары фич тащить монстра) веб и стал толстым и больным.

peregrine ★★★★★ ()
Ответ на: комментарий от suuaq

Даже в чёртовых крестах можно написать g++ file.cpp и оно будет работать.

Да ладно, а зачем тогда придумали autotools, cmake, scons и т.д. и т.п.?

static_lab ★★★★★ ()
Ответ на: комментарий от ritsufag

Ну пиши гайд, как этот комбайн во фласк запихать, раз самый вумный.

suuaq ()
Ответ на: комментарий от static_lab

Даже в чёртовых крестах можно написать g++ file.cpp и оно будет работать.

Да ладно

Таки да. Попробуй.

а зачем тогда придумали autotools, cmake, scons и т.д. и т.п.?

А пофиг. Тебе их никто не впаривает, чтобы ты мог написать хелло ворлд на крестах «современно».

suuaq ()
Ответ на: комментарий от suuaq

Таки да. Попробуй.

Да знаю я, что он так собирает. Только вот реальные проекты значительно сложнее хелло-ворлдов.

Тебе их никто не впаривает, чтобы ты мог написать хелло ворлд на крестах «современно».

На джаваскрипте ты просто этот один файл подключишь в браузер. Он тебе хелло-ворлд и выведет.

Вот только у тебя там ещё две зависимости, которые надо подключить. И их сначала установить куда-то надо. Ты же на крестах не командуешь apt-get, rpm, yum, pacman, в какие директории ему надо пакеты устанавливать? И pip устанавливает, куда ему надо. Вот и npm тоже свои пакеты и зависимости ставит туда, где их смогут другие утилиты разыскать.

static_lab ★★★★★ ()
Ответ на: комментарий от suuaq

Что значит запихать? В 2k17 фронтенд не зависит от бекенда.
Быстрее беги знакомиться со всей экосистемой node.js 😄

ritsufag ★★★★★ ()
Ответ на: комментарий от static_lab

Только вот реальные проекты значительно сложнее хелло-ворлдов.

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

Вот и npm тоже свои пакеты и зависимости ставит туда, где их смогут другие утилиты разыскать.

Это всё замечательно, но, опять, мне то оно зачем?

suuaq ()
Ответ на: комментарий от suuaq

Но ведь и проблем «по-современному» сделать — никаких:

1) создаём шаблон package.json:

npm init -y

Поскольку пакет публиковать не будешь, то со всякой ерундой вроде лицензий париться не нужно.

2) ставим нужные нам зависимости и сборщик:

npm i -S bootstrap jquery webpack

Webpack «правильнее» было бы поставить как dev-зависимость, но нам пофиг.

3) создаём main.js (или как там тебе удобнее его назвать):

var $ = global.jQuery = require('jquery');
require('bootstrap');

// далее твой код

global.jQuery нужен для бутстрапа, поскольку это старая библиотека, и она не поддерживает ни стандарт AMD, ни стандарт CommonJS.

4) в package.json в секции scripts пишем

  "scripts": {
    "build": "webpack main.js static/main.js",
    "watch": "webpack --watch main.js static/main.js"
  },

5) теперь можно легко собирать скрипт одной командой npm run build или npm run watch, чтобы вебпак следил за файлами и собирал всё автоматически.

package.json сохраняем в git, а node_modules записываем в игнор. Теперь для подготовки сборки достаточно выполнить npm i, и всё установится автоматически.

Вдобавок, в webpack можно использовать require и import для разбиения скриптов по модулям.

static_lab ★★★★★ ()
Последнее исправление: static_lab (всего исправлений: 1)
Ответ на: комментарий от static_lab

Кстати минимальный package.json может быть вообще

{
  "private": true
}

Тогда npm не будет сыпать варнинги.

static_lab ★★★★★ ()
Ответ на: комментарий от static_lab

Хмм. А файлы от бутстрапа в статик как перенести?

suuaq ()
Ответ на: комментарий от suuaq

Хмм. А файлы от бутстрапа в статик как перенести?

css?

static_lab ★★★★★ ()
Ответ на: комментарий от suuaq

Хех, а зачем тогда тебе все эти пакетные менеджеры, системы сборки?
Ты не стесняйся заходи на сайты библиотек и вручную качай последний билд, и клади в static.
Посоны во дворе не будут уважать, но мы же не за этим пришли. Мы типа работу делаем 😆
То что при обновлении библиотек/кода нужно будет изменить хэш/версию это же ненужно. Итак сойдет!

ritsufag ★★★★★ ()
Ответ на: комментарий от ritsufag

Хех, а зачем тогда тебе все эти пакетные менеджеры, системы сборки?

Причины знакомиться с экосистемой nodejs не найдены.

Ты не стесняйся заходи на сайты библиотек и вручную качай последний билд, и клади в static.

Причины знакомиться с экосистемой nodejs не найдены.

Посоны во дворе не будут уважать, но мы же не за этим пришли. Мы типа работу делаем 😆

Причины знакомиться с экосистемой nodejs не найдены.

То что при обновлении библиотек/кода нужно будет изменить хэш/версию это же ненужно. Итак сойдет!

О, что-то отдалённо похожее. Но что-то я не впечатлён.

suuaq ()
Ответ на: комментарий от ritsufag

Что, уже слился? А я надеялся что-то действительно полезное услышать, чего мне не хватает. А с хешами я, прости, и без nodejs разберусь.

suuaq ()
Ответ на: комментарий от suuaq

Шрифты и стили может и вебпак правильно собрать и разложить, но его для этого надо настраивать. В данном случае будет проще сделать ещё одну npm-таску для копирования и дописать её в build и watch.

static_lab ★★★★★ ()
Ответ на: комментарий от static_lab

Эх, ну тоска же.

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

Даже этот ваш вариант попроще качает два десятка лишних мегабайт, дуплицирует искомые файлы и требует писать руками таски. А весь профит, который я от этого вижу, это уважение рицуфага, не в обиду ему.

suuaq ()
Ответ на: комментарий от suuaq

Дело в том, что если бы некий пакетный менеджер «просто скачивал» файлы и зависимости, то их бы пришлось подключать к html вручную. Если в очередной версии зависимости изменятся, то всё сломается. Вдобавок, не будет ни объединения файлов, ни оптимизации, ни минификации.

static_lab ★★★★★ ()
Ответ на: комментарий от static_lab

то их бы пришлось подключать к html вручную. Если в очередной версии зависимости изменятся, то всё сломается.

CSS с прочими ресурсами и сейчас надо подключать вручную либо к html, либо к вебпаку, я правильно понял?

Вдобавок, не будет ни объединения файлов, ни оптимизации, ни минификации.

А от этого есть реальный профит, если у меня два скрипта на трёх страницах?

suuaq ()
Ответ на: комментарий от suuaq

В данном случае профита немного. В плане подключения: поскольку вебпак автоматически находит зависимости, то получаются один скриптовый файл и один стилевой с заранее известными именами, которые и нужно подключить на страницу независимо от того, какие и где зависимости были использованы в исходниках. В простых случаях это всё смысла не имеет, потому проще и быстрее скопировать всё ручками или подключить из CDN.

static_lab ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.