В чем разница между Bower и npm?

avatar
Games Brainiac
5 сентября 2013 в 16:53
323379
8
1844

В чем принципиальная разница между bower и npm? Просто хочется чего-то простого и понятного. Я видел, как некоторые из моих коллег использовали bower и npm как взаимозаменяемые в своих проектах.

Источник
T8y
19 марта 2014 в 12:54
9

Связанный ответ coderhelper.com/a/21199026/1310070

anotherdave
24 июля 2014 в 15:47
4

возможный дубликат управления зависимостями Javascript: npm vs bower vs volo?

amdev
5 октября 2016 в 11:48
8

Ответ на этот вопрос кажется устаревшим. Может ли кто-нибудь сказать нам, что делать в 2016 году, если мы будем использовать npm 3, поддерживающий плоскую зависимость? В чем разница wince npm3 и bower и что лучше всего делать прямо сейчас?

XML
7 января 2018 в 15:32
2

В итоге, @amdev: bower устарела. npm (или Yarn, разница лишь незначительная) - вот где он находится. Я не знаю реальных альтернатив.

Ответы (8)

avatar
Sindre Sorhus
6 сентября 2013 в 08:09
1958

У всех менеджеров пакетов есть много недостатков. Вам просто нужно выбрать, с чем вы сможете жить.

История

npm начал с управления модулями node.js (поэтому по умолчанию пакеты попадают в node_modules), но он также работает для внешнего интерфейса в сочетании с Browserify или веб-пакет.

Bower создан исключительно для внешнего интерфейса и оптимизирован с учетом этого.

Размер репо

npm намного больше, чем bower, включая JavaScript общего назначения (например, country-data для информации о стране или sorts для функций сортировки, которые можно использовать на передней или задней стороне).

Bower имеет гораздо меньшее количество пакетов.

Обработка стилей и т. Д.

Bower включает стили и т. Д.

npm ориентирован на JavaScript. Стили загружаются отдельно или требуются для чего-то вроде npm-sass или sass-npm.

Обработка зависимостей

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

Вложенное дерево зависимостей означает, что ваши зависимости могут иметь собственные зависимости, которые могут иметь свои собственные, и так далее. Это позволяет двум модулям требовать разные версии одной и той же зависимости и при этом работать. Обратите внимание, начиная с npm v3, дерево зависимостей по умолчанию будет плоским (экономия места) и будет размещаться только там, где это необходимо, например если двум зависимостям нужна собственная версия Underscore.

Некоторые проекты используют оба: они используют Bower для интерфейсных пакетов и npm для инструментов разработчика, таких как Yeoman, Grunt, Gulp, JSHint, CoffeeScript и т. Д.


Ресурсы

Lars Nyström
19 января 2014 в 16:41
37

Почему вложенное дерево зависимостей не справляется с этой задачей во внешнем интерфейсе?

Steven Vachon
24 января 2014 в 02:51
24

Может ли интерфейсный пакет npm не быть плоским деревом зависимостей? Я сталкиваюсь с вопросом "зачем нам 2 менеджера пакетов?" дилемма.

Sindre Sorhus
25 января 2014 в 17:41
9

@StevenVachon, конечно, но их очень мало, так что на это нельзя положиться. Лучше использовать npm dedupe и просматривать, если вы хотите использовать npm для интерфейсного управления пакетами.

mvmn
17 октября 2014 в 02:42
38

Что вы подразумеваете под «плоским деревом зависимостей»? Плоское дерево это что - список? Значит, это не дерево.

Jørgen Fogh
25 декабря 2014 в 17:20
15

Собственно, путь - это тоже дерево. Это просто особый случай. Из WikiPedia: «В математике, а точнее в теории графов, дерево - это неориентированный граф, в котором любые две вершины соединены ровно одним путем».

Danny
30 июля 2015 в 19:29
1

Я до сих пор не понимаю, почему я предпочитаю использовать дерево вместо того, чтобы держать вещи плоскими. Почему бы вам не иметь возможность иметь несколько версий определенных пакетов со сглаженными зависимостями? Не могли бы вы просто включить в имена зависимостей номера версий? Дерево кажется слишком сложным, особенно с учетом ограничений пути в Windows. И npm dedupe, после того, как я немного поигрался с ним, кажется полон проблем.

Sindre Sorhus
31 июля 2015 в 11:09
5

@Danny Дерево зависимостей - это то, как работает разрешение зависимостей, а не то, как оно расположено на диске. npm @ 3 будет устанавливать зависимости как можно более плоскими по умолчанию, чтобы в большинстве случаев обойти ограничения пути Windows. Логика Node.js require не будет работать с версией в именах папок. Возможно, вы могли бы получить что-то работающее с каким-то сумасшедшим символическим связыванием, но символьные ссылки тоже не подходят для Windows. Вы можете узнать больше о npm @ 3 здесь: github.com/npm/npm/releases/tag/v3.0.0

vasa
21 ноября 2015 в 06:55
42

npm 3 теперь поддерживает плоское дерево зависимостей.

Karel Bílek
24 декабря 2015 в 13:52
4

Когда я использую новейшие npm и node (в декабре 2015 года), у меня все равно была плоская зависимость (это наиболее очевидно, когда вы node_modules и получаете сотни подпапок вместо одной). Так в чем же разница сейчас ?

oligofren
10 февраля 2016 в 00:23
3

vasa и @ KarelBílek: Вы путаете структуру диска с абстрактной моделью. Дерево зависимостей ни в коем случае не является плоским, но NPM3 всегда будет пытаться переместить общие зависимости как можно дальше вверх по дереву каталогов. См. Ссылку в комментариях Синдре прямо перед вашей. Прокрутите вниз до "Плоский, плоский, плоский!" в примечаниях к выпуску, чтобы понять, что на самом деле происходит.

mummybot
25 февраля 2016 в 12:49
3

На самом деле никто не ответил на вопрос @ LarsNyström (хотя он был в исходном ответе): «Вложенное дерево зависимостей означает, что ваши зависимости могут иметь свои собственные зависимости, которые могут иметь свои собственные, [i] представьте, что сайт должен загрузить три копии jQuery . " например библиотека X зависит от jQuery 1.0, библиотека Y зависит от библиотеки Y.01, которая зависит от jQuery 1.2, библиотека Z зависит от jQuery 2.0. Прекрасно для разработки, но не годится, если пользователю нужно загрузить все три версии jQuery в своем браузере.

Stefano Borini
13 мая 2016 в 12:39
5

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

Jasmine
2 августа 2016 в 04:40
0

@SindreSorhus: Вы, кажется, написали что-то о npm, что вас не устраивает. NOM предназначен не только для узла, он предназначен для установки всех плагинов, фреймворков, приложений и библиотек.

amdev
5 октября 2016 в 11:46
6

Этот ответ устарел. Можете ли вы обновить и сообщить нам, что делать в 2016 году, если мы будем использовать npm 3, который поддерживает плоскую зависимость?

avatar
XML
26 июля 2015 в 03:12
281

TL; DR: самая большая разница в повседневном использовании - это не вложенные зависимости ... это разница между модулями и глобальными объектами.

Я думаю, что предыдущие плакаты хорошо освещали некоторые из основных различий. (Использование вложенных зависимостей в npm действительно очень полезно при управлении большими и сложными приложениями, хотя я не думаю, что это самое важное различие.)

Я удивлен, однако, тем, что никто явно не объяснил одно из самых фундаментальных различий между Bower и npm. Если вы прочитаете ответы выше, вы увидите, что слово «модули» часто используется в контексте npm. Но это упомянуто случайно, как будто это может быть просто синтаксическая разница.

Но это различие между модулями и глобальными объектами (или модулями и «скриптами»), возможно, является наиболее важным различием между Bower и npm. Подход npm, заключающийся в размещении всего в модулях, требует, чтобы вы изменили способ написания Javascript для браузера, почти наверняка в лучшую сторону.

Подход Бауэра: глобальные ресурсы, например, <script> Теги

В корневом каталоге Bower загружает старые файлы сценариев. Что бы ни содержали эти файлы сценариев, Бауэр загрузит их. По сути, это означает, что Bower - это то же самое, что включать все ваши скрипты из простых <script> в <head> вашего HTML.

Итак, тот же базовый подход, к которому вы привыкли, но при этом вы получаете удобство автоматизации:

  • Раньше вам нужно было включить зависимости JS в репозиторий вашего проекта (при разработке) или получить их через CDN. Теперь вы можете пропустить этот дополнительный вес загрузки в репо, и кто-нибудь может быстро выполнить bower install и мгновенно получить то, что ему нужно, локально.
  • Если зависимость Bower затем указывает свои собственные зависимости в своем bower.json, они также будут загружены для вас.

Но помимо этого, Bower не меняет способ написания javascript . Ничего из того, что находится внутри файлов, загружаемых Bower, вообще не нужно менять. В частности, это означает, что ресурсы, предоставляемые в скриптах, загружаемых Bower, будут (обычно, но не всегда) по-прежнему определяться как глобальные переменные , доступные из любого места в контексте выполнения браузера.

Подход npm: общие модули JS, явное внедрение зависимостей

Весь код в области Node (и, следовательно, весь код, загруженный через npm) структурирован как модули (в частности, как реализация формата модуля CommonJS, или теперь как модуль ES6). Итак, если вы используете NPM для обработки зависимостей на стороне браузера (через Browserify или что-то еще, выполняющее ту же работу), вы структурируете свой код так же, как это делает Node.

Более умные люди, чем я, занялись вопросом «Почему модули?», Но вот краткое изложение:

  • Все, что находится внутри модуля, фактически имеет ​​пространство имен , что означает, что это больше не глобальная переменная, и вы не можете случайно ссылаться на нее без намерения.
  • Все, что находится внутри модуля, должно быть намеренно введено в конкретный контекст (обычно другой модуль), чтобы его можно было использовать
  • Это означает, что у вас может быть несколько версий одной и той же внешней зависимости (скажем, lodash) в различных частях вашего приложения, и они не будут конфликтовать / конфликтовать. (Это происходит на удивление часто, потому что ваш собственный код хочет использовать одну версию зависимости, но одна из ваших внешних зависимостей указывает другую, которая конфликтует. Или у вас есть две внешние зависимости, каждой из которых нужна другая версия.)
  • Поскольку все зависимости вручную вводятся в конкретный модуль, их очень легко рассуждать. Вы знаете наверняка: «Единственный код, который мне нужно учитывать при работе над этим, - это то, что я намеренно выбрал для введения сюда» .
  • Поскольку даже содержимое внедренных модулей инкапсулировано за переменной, которой вы его назначаете, и весь код выполняется в ограниченной области, неожиданности и коллизии становятся очень маловероятными. Гораздо, гораздо менее вероятно, что что-то из одной из ваших зависимостей случайно переопределит глобальную переменную без вашего ведома или что вы это сделаете. (Это может случиться, но обычно для этого нужно изо всех сил стараться сделать это с чем-то вроде window.variable. Единственная авария, которая все еще имеет тенденцию происходить, - это присвоение this.variable, не осознавая, что this на самом деле является window в текущем контексте.)
  • Когда вы хотите протестировать отдельный модуль, вы можете очень легко узнать: что еще (зависимости) влияет на код, выполняемый внутри модуля? А поскольку вы явно все вводите, вы можете легко имитировать эти зависимости.

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


Чтобы научиться использовать синтаксис модуля CommonJS / Node, требуется всего около 30 секунд. Внутри данного JS-файла, который будет модулем, вы сначала объявляете любые внешние зависимости, которые хотите использовать, например:

var React = require('react');

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

В конце файла вы экспортируете все, чем хотите поделиться с миром, например:

module.exports = myModule;

Затем, чтобы использовать рабочий процесс на основе CommonJS в браузере, вы будете использовать такие инструменты, как Browserify, чтобы захватить все эти отдельные файлы модулей, инкапсулировать их содержимое во время выполнения и вставить их друг в друга по мере необходимости.

И, поскольку модули ES6 (которые вы, вероятно, перенесете в ES5 с помощью Babel или аналогичных) получают широкое распространение и работают как в браузере, так и в Node 4.0, мы должны упомянуть хороший обзор из них тоже.

Подробнее о шаблонах для работы с модулями в этой колоде.


РЕДАКТИРОВАТЬ (февраль 2017 г.): Facebook - очень важная потенциальная замена / дополнение для npm в наши дни: быстрое, детерминированное, автономное управление пакетами, основанное на том, что дает вам npm. Стоит взглянуть на любой JS-проект, тем более, что его очень легко заменить / вывести.


ИЗМЕНИТЬ (май 2019 г.) «Бауэр, наконец, был устаревшим. Конец истории». (h / t: @DanDascalescu, ниже, для краткого резюме.)

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

Juan Mendes
13 мая 2016 в 13:06
13

Рад, что этот ответ был здесь, в других популярных ответах эта деталь не упоминается. npm заставляет вас писать модульный код.

Pedro Rodrigues
21 ноября 2018 в 21:00
0

Прошу прощения, от людей, которые очень мало заботятся обо всей фаззинге в javascript parlands, но так случилось, что он управляет бизнесом, который использует небольшое веб-приложение. Недавно был вынужден попробовать npm из-за использования bower с набором инструментов, который мы используем для разработки чертовски веб-вещей. Я могу вам сказать, что самая большая разница - это время ожидания, npm занимает много времени. Помните, что это сборка мультфильма xkcd с парнями, играющими на мечах и кричащими «компилирование» своему боссу; это в значительной степени то, что npm добавила в беседку.

avatar
Dan Dascalescu
4 июля 2015 в 10:48
136

Обновление за октябрь 2017 г.

Наконец-то Bower устарел. Конец истории.

Предыдущий ответ

От Маттиаса Петтера Йоханссона, разработчика JavaScript в Spotify:

Почти во всех случаях более целесообразно использовать Browserify и npm вместо Bower. Это просто лучшее упаковочное решение для интерфейсных приложений, чем Bower. В Spotify мы используем npm для упаковки целых веб-модулей (html, css, js), и это работает очень хорошо.

Bower позиционирует себя как менеджер пакетов для Интернета. Было бы здорово, если бы это было правдой - менеджер пакетов, который сделал бы мою жизнь лучше как фронтенд-разработчика, был бы потрясающим. Проблема в том, что Bower не предлагает специальных инструментов для этой цели. Он не предлагает НИКАКИХ инструментов, о которых я знаю, чего нет в npm, и особенно ничего, что было бы особенно полезно для интерфейсных разработчиков. Интерфейсному разработчику просто не выгодно использовать Bower по сравнению с npm.

Мы должны прекратить использовать bower и консолидироваться около npm. К счастью, именно это и происходит :

Module counts - bower vs. npm

С помощью browserify или webpack становится очень легко объединить все ваши модули в большие минифицированные файлы, что обеспечивает отличную производительность, особенно для мобильных устройств. Иначе обстоит дело с Bower, для получения такого же эффекта потребуется значительно больше труда.

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

(Обратите внимание, что Webpack и накопительный пакет широко считаются лучше, чем Browserify по состоянию на август 2016 г.)

Mariusz Jamro
11 декабря 2016 в 18:36
9

<sarcasm> Имейте в виду, что даже проекту npm 'hello world' требуется более 300 модулей для запуска ... </sarcasm>: O

Michael Franzl
9 апреля 2017 в 14:03
2

Я не согласен с тем, что «большие минифицированные файлы» «хороши для производительности, особенно для мобильных устройств». Скорее наоборот: ограниченная пропускная способность требует небольших файлов, загружаемых по запросу.

Gerardo Grignoli
11 апреля 2017 в 17:59
0

Не очень хороший совет. Большинство пакетов npm - это только серверная часть nodejs. Если вы не используете javascript на бэкэнде или у вас нет модульной системы, количество пакетов не имеет значения, потому что Bower будет намного лучше соответствовать вашим потребностям.

Dan Dascalescu
12 апреля 2017 в 08:30
4

@GerardoGrignoli: беседка на пути к выходу.

avatar
Nick Heiner
16 февраля 2015 в 21:04
36

Моя команда переехала из Бауэра и перешла на npm, потому что:

  • Использование алгоритмических продаж было болезненным
  • Интерфейс Бауэра постоянно менялся
  • Некоторые функции, например сокращение URL, полностью не работают
  • Использование Bower и npm в одном проекте болезненно
  • Сохранять синхронизацию поля версии bower.json с тегами git - это больно
  • Контроль версий! = Управление пакетами
  • Непростая поддержка CommonJS

Подробнее см. «Почему моя команда использует npm вместо bower».

avatar
Justus Romijn
24 ноября 2014 в 13:10
369

Этот ответ является дополнением к ответу Синдре Сорхуса. Основное различие между npm и Bower заключается в том, как они обрабатывают рекурсивные зависимости. Обратите внимание, что их можно использовать вместе в одном проекте.

На FAQ по npm: (ссылка на archive.org от 6 сентября 2015 г.)

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

На домашней странице Bower:

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

Короче говоря, npm стремится к стабильности. Bower стремится к минимальной ресурсной нагрузке. Если вы вытянете структуру зависимостей, вы увидите следующее:

npm:

project root
[node_modules] // default directory for dependencies
 -> dependency A
 -> dependency B
    [node_modules]
    -> dependency A

 -> dependency C
    [node_modules]
    -> dependency B
      [node_modules]
       -> dependency A 
    -> dependency D

Как видите, он устанавливает некоторые зависимости рекурсивно. У зависимости A три установленных экземпляра!

Бауэр:

project root
[bower_components] // default directory for dependencies
 -> dependency A
 -> dependency B // needs A
 -> dependency C // needs B and D
 -> dependency D

Здесь вы видите, что все уникальные зависимости находятся на одном уровне.

Итак, зачем использовать npm?

Возможно, для зависимости B требуется другая версия зависимости A, чем для зависимости C. npm устанавливает обе версии этой зависимости, поэтому она все равно будет работать, но Bower даст вам конфликт , потому что не любит дублирование ( потому что загрузка того же ресурса на веб-страницу очень неэффективна и затратна, а также может привести к серьезным ошибкам). Вам придется вручную выбрать, какую версию вы хотите установить. Это может привести к тому, что одна из зависимостей сломается, но это то, что вам все равно нужно будет исправить.

Таким образом, Bower обычно используется для пакетов, которые вы хотите опубликовать на своих веб-страницах (например, runtime , где вы избегаете дублирования), и используйте npm для других вещей, таких как тестирование, сборка, оптимизация , проверка и т. д. (например, время разработки , где дублирование менее важно).

Обновление для npm 3:

npm 3 по-прежнему работает иначе, чем Bower. Он установит зависимости глобально, но только для первой обнаруженной версии. Остальные версии устанавливаются в дереве (родительский модуль, затем node_modules).

  • [node_modules]
    • dep A v1.0
    • dep B v1.0
      • dep A v1.0 (использует корневую версию)
    • dep C v1.0
      • dep A v2.0 (эта версия отличается от корневой версии, поэтому это будет вложенная установка)

Для получения дополнительной информации я предлагаю прочитать документы npm 3

jfmercer
10 июня 2015 в 00:38
4

Сейчас это уже почти клише, что «разработка программного обеспечения - это всегда компромиссы». Это хороший пример. Необходимо выбрать либо большую стабильность с npm , либо минимальную нагрузку на ресурсы с bower.

Justus Romijn
10 июня 2015 в 08:25
6

@Shrek Я неявно заявляю, что вы действительно можете использовать и то, и другое. У них разные цели, как я заявляю в последнем абзаце. На мой взгляд, это не компромисс.

jfmercer
10 июня 2015 в 14:38
0

Ах, я вижу, я тебя неправильно понял. Или я недостаточно внимательно прочитал. Спасибо за разъяснения. :-) Хорошо, что и то и другое можно использовать без компромиссов.

Justus Romijn
18 января 2016 в 10:13
4

@AlexAngas Я добавил обновление для npm3. Он все еще имеет некоторые существенные отличия от Bower. npm, вероятно, всегда будет поддерживать несколько версий зависимостей, а Bower - нет.

ni3
21 марта 2017 в 06:40
0

npm 3 приближается к беседке;)

avatar
jessopher
11 октября 2014 в 20:42
6

Для многих людей, работающих с node.js, основным преимуществом bower является управление зависимостями, которые вообще не являются javascript. Если они работают с языками, которые компилируются в javascript, npm можно использовать для управления некоторыми их зависимостями. однако не все их зависимости будут модулями node.js. Некоторые из тех, которые компилируются в javascript, могут иметь странные специфические особенности исходного языка, что делает их передачу скомпилированными в javascript неэлегантным вариантом, когда пользователи ожидают исходный код.

Не все в пакете npm должно быть ориентировано на пользователя javascript, но для пакетов библиотеки npm, по крайней мере, некоторые из них должны быть.

Dan Dascalescu
4 июля 2015 в 10:28
0

В этом сообщении блога npmjs говорится: «Ваш пакет может содержать что угодно, будь то ES6, клиентский JS или даже HTML и CSS. Это вещи, которые естественно появляются вместе с JavaScript, поэтому поместите их туда». .

jessopher
9 декабря 2015 в 02:43
1

Существует разница между может содержать и должен включать . Конечно, они могут содержать что угодно, но в целом они должны включать какой-то интерфейс для commonJS. В конце концов, это «менеджер пакетов узлов». Часть о . Это вещи, которые естественно появляются вместе с Javascript . Есть много вещей, косвенно связанных с javascript, которые не естественно появляются рядом с ним .

avatar
Henry Neo
3 октября 2014 в 00:08
18

Нашел это полезное объяснение на сайте http://ng-learn.org/2013/11/Bower-vs-npm/

С одной стороны, npm был создан для установки модулей, используемых в среде node.js, или инструментов разработки, созданных с использованием node.js, таких как Karma, lint, minifiers и т. Д. npm может устанавливать модули локально в проекте (по умолчанию в node_modules) или глобально для использования в нескольких проектах. В больших проектах можно указать зависимости путем создания файла с именем package.json, который содержит список зависимостей. Этот список распознается npm, когда вы запускаете npm install, которая затем загружает и устанавливает их для вас.

С другой стороны, bower был создан для управления зависимостями вашего внешнего интерфейса. Такие библиотеки, как jQuery, AngularJS, подчеркивание и т. Д. Подобно npm, у него есть файл, в котором вы можете указать список зависимостей, который называется bower.json. В этом случае зависимости вашего внешнего интерфейса устанавливаются путем запуска bower install, который по умолчанию устанавливает их в папку с именем bower_components.

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

Dan Dascalescu
4 июля 2015 в 10:49
1

С появлением npm dedupe это немного устарело. См. ответ Маттиаса.

avatar
Sagivf
19 июля 2014 в 20:59
48

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

Управление зависимостями Javascript: npm vs bower vs volo?

NPM лучше подходит для узловых модулей, потому что есть модульная система и вы работаете локально. Bower хорош для браузера, потому что в настоящее время существует только глобальная область видимости, и вы хотите очень избирательно подходить к версии, с которой работаете.

Games Brainiac
19 июля 2014 в 21:21
4

Я чувствую, что Синдре упоминает это, когда говорит о вложенной зависимости.

Sagivf
20 июля 2014 в 11:01
5

@GamesBrainiac, ты прав, просто подумал, что перескажу своими словами.

dayuloli
3 марта 2015 в 06:36
1

@Sagivf Это НЕ ваши собственные слова, если только вы не являетесь тем, кто предоставил здесь исходный ответ

Sagivf
4 марта 2015 в 10:35
0

@dayuloli, это был мой первый пост на coderhelper, и я не понимал, что авторские права так важны. Мне понравился ответ, поэтому я использовал его. Я изменил сообщение. Когда я сказал свои слова, я даже не вспомнил, что взял их откуда-то еще.

dayuloli
4 марта 2015 в 10:39
4

@Sagivf Нет ничего плохого в копировании ** соответствующих частей других ответов, если они сами не дали здесь ответа. Меня это немного беспокоило, ты сказал: «Просто подумал, что я изложу это своими словами». Кредит должен поступать туда, где причитается.

Calvin
30 ноября 2015 в 22:04
2

Я не знаю, почему вы так сильно выбрали этот ответ. В этом ответе мне действительно есть новая информация / перспектива.