Взаимный require A из B и B из A

Получается бред

Почему бред? Модули загружаются один раз, тут нет зацикливания.

Это может работать технически, но в целом это бред, конечно. Модули должны разбивать код на логические независимые части с определенной иерархией. Два взаимнозависимых модуля — это либо один модуль (слияние двух модулей в один), либо три (с вынесением общего кода в отдельный модуль).

Что делать?

Не сцать против ветра. Взаимные зависимости - это плохо, потому что приводят к потенциальной рекурсии и выпадению волос.
То есть надо вынести всё, что нужно А и В в C и экспортировать его.

Потому что состав А потенциально влияет на то, что будет в Б и наоборот. js - динамический язычок, там набор экспортируемых функций потенциально может отличаться в зависимости от состояния рантайма. Именно поэтому так делать ни в коем случае нельзя (хотя у меня есть место, где делается именно так, кстати, надо его переписать).

Очевидно же — вынести общее в C.js

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

Но если очень хочется, то можно. Я не агитирую, если что.

Именно поэтому

Тогда зачем брать динамический язычок?

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

ты сделал ошибку где-то сильно раньше.

Если вкратце, то должно быть A require C, B require C.

А тебе компилятор говорит именно об ошибке в структурировании кода. Когда переделаешь на без ошибок, сразу увидишь, насколько всё станет проще и логичнее.

Всегда ржу над такими темами и мудрыми комментариями. В Паскале это делается так:

module a;
interface uses b;
...
implementation 
...
end.

module b;
interface
...
implementation uses a;
...
end.

Но потом люди придумали BDSM и заставили всех им заниматься. В реальности, взаимозависимые подсистемы встречаются сплошь и рядом. В языках, где их как бы нет, это решается с помощью разных костылей, например, в модуле A объявляется интерфейс и переменная, содержащая экземпляр интерфейса, а в модуле B - реализация интерфейса и инициализация переменной, находящейся в модуле A. Вроде как всё красиво и как будто бы A не зависит от B, но в реальности оба модуля зависят друг от друга и до загрузки модуля B модуль A всё равно работать не будет. Но лицемерие побеждает :)

Притом, в Паскале чётко написано, кто от кого и как зависит, и для выражения этого не нужно плодить лишних сущностей. А в «правильных языках», у тебя есть интерфейс в модуле A, а кто и как его воплощает - неизвестно без знания процесса сборки и загрузки. Т.е. вместо того, чтобы создать инструмент, отражающий реальность, запретили эту реальность и потом выразили её эзоповым языком.

Ещё более плохой способ реализации - это когда есть указатель на функцию в модуле A, который инициализируется в модуле B. При этом уже нужно изучать не структуру кода, а порядок его выполнения, чтобы определить наличие циклической взаимосвязи между A и B. И до момента, когда мы нашли место инициализации указателя, мы вообще не можем понять иерархию модулей. Кроме того, в таком способе нет защиты, например, от того, чтобы этот указатель был назначен 0 раз или более одного раза, или от чтения этого указателя до его заполнения чем надо.

Что делать

Не разбивать на два файла то что должно быть в одном. Или вынести все общее в третий

import cycles - это плохо. Надо просто по-другому структурировать код. Представь, что в момент импорта A выполняет функцию из B, которая выполняет функцию из А. Вот и приехали в бескоечный цикл и 100% загрузку процессора. А это, кстати, конечная. Поэтому и плохо :) Вывод - переписывать код.

Зацикливания нет, но в A «видит» B, а B не видит A

const a = require A
console.log(a) // {} empty onj

Пихаешь общие функции в C.js.

Динамический не язычок, а его рантайм?

Да это понятно, но это скучно. Просто не пойму что мешает сделать взаимный require

это проблема уровня курицы и яйца.

Тогда зачем брать динамический язычок?

Затем.

Но если очень хочется, то можно.

Нет, серьёзно. В этом нет смысла. Но это можно извернуться и сделать словив ворнинг.

Поцкал - статитеский недоязычок. Иди пиши еще один кодоген на пыхтоне.

интерфейс

В динамическом язычке такого нет и не нужно.

А в «правильных языках», у тебя есть интерфейс в модуле A, а кто и как его воплощает - неизвестно без знания процесса сборки и загрузки. Т.е. вместо того, чтобы создать инструмент, отражающий реальность, запретили эту реальность и потом выразили её эзоповым языком.

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

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

но в A «видит» B, а B не видит A

Надо require делать внутри функции. Типа

const A = () => require("A");

Тогда во время загрузки B не будет требоваться A, а только при первом использовании.

console.log(a) // {} empty onj

Потому что в этот момент A который начал загружаться раньше, ещё ничего не экспортировал. Тебе нужно отложить момент требования, например как я написал выше. Получится

const A = () => require("A");

...

function somethingUsingA() {
   ...
   A().fromA() // В этот момент A будет уже полностью загружен
}

Другой вариант, передавать модуль явно как параметр и убрать взаимный require.

const A = require('A') // внутри B явно не требуется
const B = require('B') // внутри A явно не требуется

// Функции в A и B
function someFoo(A,B) {
   ...
}

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

Но кстати и в сях тоже можно:

// a.c

#include "a.h"
#include "b.h"
...
//eof


// b.c
#include "b.h"
#include "a.h"
...
//eof

Хоть это и не модули, но с помощью заголовочников их можно в определённой степени имитировать.

В Оракле в PL/SQL тоже есть пакеты и ты их можешь создавать и модифицировать динамически

Ага, динамически. Вся эта шляпа повисает при компиляции, если кто-то пользуется пакетом в этот момент. А потом первый вызов изменённого пакета падает с ошибкой. Костыль на костыле.

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

Да что далеко ходить. В жабке можно на ходу грузить классы. Только делать там перезагрузку это всё равно, что ухо чесать пяткой через анал. Проще рестарт сделать.

Ага, динамически. Вся эта шляпа повисает при компиляции, если кто-то пользуется пакетом в этот момент. А потом первый вызов изменённого пакета падает с ошибкой. Костыль на костыле.

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

Да что далеко ходить. В жабке можно на ходу грузить классы.

Так они много фич из оберона сперли.

В реальности, взаимозависимые подсистемы встречаются сплошь и рядом.

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

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