Мне один раз тоже такое пригодилось, кстати.

Но это была зависимость по нормальному имени, не относительному пути.

форк - означает его поддержку

я не хочу поддерживать весь форк, мне нужно переопределить 1 файл

Относительный путь - это значит что ты хочешь часть либы поменять. Та, которую авторы не предполагали отделять как-либо от либы. А для этого есть правильный путь и тот что ты хочешь прикрутить. Нет разницы поддерживать файл или форк :) У тебя твой файл будет ломаться и требовать фиксов/поддержки с точно таким же интервалом как и форк :)

по сути ты точно так же поддерживаешь файл

Так а в чем сложность поддерживать форк?

Просто мерджить его с оригинальным репозиторием периодически

на самом деле все не так)

файл - обновляешь зависимость, чинишь если поломалось. Форк - мержишь апстрим (обновляешь зависимость), чинишь что поломалось, пушишь, обновляешь зависимость в аппе Если последние два действия очень напрягают то да, сложно. Если нет, то легко

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

представь библиотеку компонентов, это не так, но представь

вот я хочу дать возможность переопределить кнопку

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

А в чем проблема тогда сделать для этого прогаммный интерфейс?

Зачем через webpack'и это делать, когда существуют более подходящие практики для этого?

например? проект же ты вебпаком собираешь

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

Так продумай интерфейс для переключения нужного компонента. Не знаю, там setComponentLayer(new CustomComponentLayer)?

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

программный интерфейс предполагает ограничения

если я что-то не запрограммирую - это невозможно переопределить

Но ты хочешь поменять модуль

Это в принципе нельзя переопределить, если ты это не запрограммируешь)

ну смотри, у тебя по дефолту используется lodash

Модуль же что-то делает

любой интерфейс предполагает ограничения. Если ты хочешь возможность менять либу без ограничений - я тебе уже сказал как это правильно делается ;)

Но у либы есть метод, типа setLibrary

Ты хочешь переопределить его стандартное поведение.

Или расширить

И ты можешь в него передать underscore или еще чего

ребята, вы что-то сложное говорите)

вот есть кнопка

тупая

у нее известен интерфейс

есть библиотека UI, которая использует эту кнопку

и таких компонентов "кнопок" 100шт еще разных

Таак

А в чем проблема?

так вот мне нужно понять, как в вебпак прокинуть пути для переопределения вот и все)

theme-style?

Если тебе надо переопределять что-то вроде темы (одна кнопка заменяется другой и т.п.), то тогда есть смысл определять некий параметр current theme и от него собирать.

кнопка - это пример. Это может быть что угодно. То, как выглядит сообщение, например

Я так понимаю, у тебя должна быть структура типа themes/ A/ /button.jsx B/ /button.jsx

Мне кажется, что ты пытаешься сделать что-то очень странное

Допустим, у тебя есть либа

А ты вот хочешь что-то вроде THEMEID=A webpack ...

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

?

ох)

Наверняка у твоей задачи есть более нормальные решения. Но если ты хочешь решать ее именно так - то никто тебя конечно не остановит )

А которой есть кнопка, типа someLibrary.button. Как выходит, что ты не можешь просто сделать someLibrary.button = anotherButton

в общем вы не знаете как в вебпаке это переопределить - ок, не вопрос)

ну так вот самое просто и логичное это программный интерфейс lib.init({ button: require('./my-own-elephant-button.js') })

А которой есть кнопка, типа someLibrary.button. Как выходит, что ты не можешь просто сделать someLibrary.button = anotherButton

А не проще сделать импорт нужной темы?

ну так вот самое просто и логичное это программный интерфейс lib.init({ button: require('./my-own-elephant-button.js') })

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

в общем вы не знаете как в вебпаке это переопределить - ок, не вопрос)

Ты можешь написать свой резолвер, если стандарные возможности не подходят. Ультимейт солюшен.

так я спросил - есть ли стандартная возможность)))

написать понятно, что можно

если ты автор либы - юзай алиасы прямо в ней, самое простое решение

алиасы саму на себя

А тебе принципиально в сборке не нужны другие компоненты, как я понял?

Т.е. тебе нужно все это на уровне сборки собрать, чтобы лишнего не было?

это скорее плюс такого подхода, а не самоцель

цель - дать возможность переопределить вообще что угодно

На уровне сборки?

да

ERROR: S client not available

это вредная утопия )

на уровне рантайма сейчас есть

и это не удобно

а ты что предлагаешь?)

Я бы предложил темы.

тема - это ограниченная штука

как минимум это "все что угодно" должно быть ограничено.

вот есть сообщение - тут можно кучу вещей изменить

Есть у тебя структура проекта, ты ее можешь дублировать в themes/custom директории по именам сборок, например.

И подсасывать от туда.

не, это sdk

Хотя я все равно не понимаю, зачем это на уровне сборки.

то есть подтягивается как npm модуль

потому что на уровне рантайма это надо учитывать во время разработки

А что именно "что угодно" для тебя?

Это чревато как минимум тем, что если код, который требует этой либы, будет абсолютно непонятен никому, кроме тябя

наоборот код становится чище

вот смотрите

я пишу require('../common/Button')

дальше кто-то идет и переопределяет этот button на уровне сборки

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

вот ща хороший пример покажу

Давай

А то прям вообще не понятно.

смотрите

есть babel-runtime

как babel предлагает оверайтить его

require('babel-runtime/core/promise').default = require('bluebird')

вот вы мне тоже самое предлагает

а я хочу это на уровне сборки. Что в этом желании не нормального?

Ну ок, теоретически идею понял. Хотя, скажем так, у babel реализация тоже корявая.

Тогда тебе нужна некая карта переопределения и резолвер.