ну то есть контракт неявный выходит

и только

есть масса языков где контракты неявные

А есть меинстрим язык с явными?

ну java-like

python, ruby, golang - неявно

по сути - duck typing

то что экспоузит модуль

Также можно сказать, что публичная часть класса интерфейс и интерфейсы не использовать

если у модуля есть функция такая-то значит подходит

и у тебя по сути late binding)

Также можно сказать, что публичная часть класса интерфейс и интерфейсы не использовать

интерфейсы тебе нужны по сути для диспетчеризации больше

import export в js в компайл тайме ж

import export в js в компайл тайме ж

и? я не вижу в этом проблемы

в языках типа java ты тоже обычно конфиг контейнера правишь и потом перезапускаешь апу

да даже в php

мне надо дапнуть новый контейнер

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

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

Достаточно поправить конфиг или мэин

import export в js в компайл тайме ж

ну, на клиенте systemjs, а на сервере в commonjs, а там уже можно подменить require, чтобы выдавать нужное

ну, на клиенте systemjs, а на сервере в commonjs, а там уже можно подменить require, чтобы выдавать нужное

Я про esm

Делаем вид, что он везде работает)

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

на клиент всегда компиляция будет, так что пофиг

Это да

точнее минификация и байдлинг

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

так ты и не трогаешь, трогаешь только резолюцию ну мол какой модуль ресолвить

во всяком случае при таком раскладе разницы на самом деле никакой

а вот если не можешь подменить - тогда у тебя проблемы)

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

так ты и не трогаешь, трогаешь только резолюцию ну мол какой модуль ресолвить

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

То совсем хорошо

Но вот есть сейчас яп, в котором конфиг резолва сделан каким-то стандартным способом и все тулзы подхватывают project-specific настройки?

Эм. Я зачем?

Для ide это важным быть не должно, а во время выполнения можешь крутить require в js как угодно

Но вот есть сейчас яп, в котором конфиг резолва сделан каким-то стандартным способом и все тулзы подхватывают project-specific настройки?

python не подходит?

нет

Для ide это важным быть не должно, а во время выполнения можешь крутить require в js как угодно

Ну вот как раз перейти к конкретной реализации прямо из ide

Ты же тут заливаешь про интерфейсность модулей

В линте проверить соответствие типов

Никаких конкретных реализаций

В линте проверить соответствие типов

тоже интерфейсность

тоже интерфейсность

Как проверить, что модуль соответствует интерфейсу?

И какому он должен соответствовать?

Такому, который ты где-то описал. Ты ведь его описал, чтобы любой мог свою реализацию написать, верно?

Такому, который ты где-то описал. Ты ведь его описал, чтобы любой мог свою реализацию написать, верно?

Кто как это проверит?

Не знаю умеет ли какой линтер смотреть в module.exports, но запилить это не проблема

Не знаю умеет ли какой линтер смотреть в module.exports, но запилить это не проблема

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

мб можно с внешней стороны попробовать: const a: IModule = require('a'), но не думаю, что прокатит хотя бы у кого-то

Так а в module.exports чего?

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

Подменяя require

commonjs объект там

Возьмем для простоты esm

Там все статическое

нет, простота это commonjs

Так что бери его, если хочешь

Там динамика

Там непросто)

Это неважно. После инициализации там всё как обычно

Там как раз просто, нет никаких default

Как статически проверить соответствие?

В любом случае, никто не мешает перегнать в commonjs, а его чекать указанным образом

Там как раз просто, нет никаких default

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

Как статически проверить соответствие?

Так же как проверять другие объекты

С дефолт

Так же как проверять другие объекты

В общем случае никак? Тогда не подходит

Так же как проверять другие объекты

но подменяя require ты узнаешь о зависимостях только в рантайме

ERROR: S client not available

Это ещё одна концепция, в терминах commonjs невыразимая.

Это проблемы cjs

но подменяя require ты узнаешь о зависимостях только в рантайме

Тебя не должно это в компайлтайме волновать

Это проблемы cjs

С чего вдруг?

концепции default нет нигде

А если сборщик узнает (посредством плагина) о том, как ты резолвишь, то и в компайлтайме можно

Для какого-нибудь webpack-а раз плюнуть написать

Если не ошибаюсь, для browserify был какой-то способо даже перезаписать через конфиг

Тебя не должно это в компайлтайме волновать

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

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

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

А что там за резолвом тебя волновать не должно

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

у тебя нет интерфейсов

ну то есть не совсем так

Тогда у тебя нет и контрактов

они у тебя есть

но неявные

И как они описаны?

типа

const foo = require('foo');

вот

И что?

точнее даже так

import {doStuff} from 'foo'

вот мой "контракт"

Эм. Это просто интерфейс

должен быть метод doStuff который делает то что мне нужно

что есть какой-то doStuff

должен быть метод doStuff который делает то что мне нужно

Это ты вообще никогда нигде не проверишь

Эм. Это просто интерфейс

то есть контракт)

Разве что в каких-то adga

то есть контракт)

Интерфейс частный случай. Ты сказал, что их нет

Это ты вообще никогда нигде не проверишь

нормальный IoC контейнер позволяет проверять то ли ты забиндил