Почему я «мучаюсь» с JS

Можете пояснить в чём именно проблема с отдельным импортом? Только тем что одной строчкой кода больше? Зато в одном месте можно посмотреть все зависимости файла - это же удобно! Плюс если несколько раз используется тип не надо указывать путь повторно.

Все нормальные IDE делают автоимпорт сами - так что печатать даже меньше надо.

Я например пишу на совершенно разных языках (C#, TypeScript, Python, Go) и кто там как импортирует меня меньше всего волнует. Выбираешь язык под задачу и вперёд. По мне так TypeScript на порядок лучше JavaScript - переполз после 15 лет JS на TS и безумно рад. Никогда не пойму зачем страдать с JS если есть TS.

del

Наблюдая за вашими комментариями под статьями, складывается впечатление, что вы не понимаете, зачем вам TS

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

На все вопросы даже в этой статье есть ответ. Бандлеры (роллап, вебпак, даже тот же гальп как таскраннер), плагины к ним делают те вещи, которые вы хотите, но не так, как вы хотите.

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

К чему эта демагогия?

В пределах одного пакета вполне можно писать вот так:

import { UserService } from '../users';

class UserController {
    constructor(private readonly userService: UserService) {}
}

Достаточно добавить ../users/index.ts с содержанием типа:

export * from './user';
export * from './user.service';
// etc

...и не использовать default export.

Ну и, как выше уже писали, IDE вполне способна сама сгенерировать import для вас. Не нужно делать это руками. Вы ведь в Java вручную import не пишете? Это просто потеря времени.

Современные IDE уменьшают необходимость ручного набора.

Я вставлю тип в код, нажимаю Alt+Enter, у меня появляется список, откуда можно импортировать этот тип. Если есть только один источник - и списка не появляется, сразу автоматически ставится import

Я нажимаю Alt+Shift+O - и неиспользуемые импорты в начале файла исчезают. Так работают современные IDE.

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

В Java можно обойтись только public-private, потому что там 1 класс на 1 файл. В JS/TS файле нет таких ограничений. Можно вообще хранить только функции или константы. Поэтому возникает необходимость в export - чтобы отделить внутренние функции модуля от тех, которые мы позволяем использовать.

а в Java так не писали вообще никогда (Java'вский import ничего не подгружает, а работает как alias, можно и без import'ов, если указывать полные имена классов)

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

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

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

Пс, в джаве с версии 9 тоже есть возможность/необходимость указывать экспорты для модулей. Если бы не backward compatibilty, возможно это сделали бы настройкой по умолчанию.

Соболезную всем кто с вами вынужден работать.

По поводу кода вам всё верно написали. Есть большая проблема в типизации аргумента-объекта на TS?

Я бы на код ревью ещё написал — зачем создавать методы внутри конструктора, когда можно определить всё в классе? Дальнейшей типизации это тоже не поможет.

Это я к тому, что данный код выглядит неприятно в целом.

И правильно, что за вас его никто не написал нормально, потому что нужно примерно всё написать аккуратнее и иначе, и это то что надо сделать кроме типизации.

Вы бы ещё удивлялись, почему на PHP нельзя писать как на ассемблере. Тоже можно написать статью, как вы «мучаетесь» с PHP.

Что вы набросились на дедушку? В СССР тайпскрипта не было!

Его можно понять.

Я плохо уловил смысловую нить текста, но возможно автору стоит посмотреть https://angular.io/guide/architecture-modules

Я также не понял, чем отличается

    \Magento\Framework\App\Action\Context $context,

от

   require("Magento/Framework/App/Action").Context context,

Вообще при помощи мата и пластыря глобального объекта и Proxy можно попробовать реализовать что-то вроде (насчет синтаксиса не уверен):

Magento.Framework.App.Action.Context context,

При этом стоит помнить, что

• Импортируемые файлы в ES / TS — это всё-таки модули, и у них есть определенные правила инициализации. Например функция, которую вы импортируете в JS, может хранить в своем замыкании результат вычислений, полученный при первом обращении к модулю.

• У вас скорее всего отлетит tree-shaking, не говоря уже о module-federation, хотя на бэке это не будет существенно.

Мне наоборот нравится наличие импортов в мире JS/TS - импортируешь в свой модуль ровно то, что в нем будет использоваться. В итоге у тебя ничего лишнего в подсказке нет - раз. Если будешь смотреть этот файл через энное количество времени - сразу с первых строчек понятно - что в нем будет использоваться - очень удобно.

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

Импорты в ES2015+ существуют в таком виде потому что это необходимо браузерам для статического анализа файла и предзагрузки файлов-зависимостей. Только после этого происходит выстраивание полного AST программы, и начинается компиляция в байт-код. Именно поэтому не подходят варианты in situ, как в PHP или Java, именно поэтому отказались и от нодовского require, который подгружал файл-зависимость прямо на месте. И именно поэтому динамический импорт (который import()) — асинхронный.

Что касается использования файловой системы вместо модульной, то причина всё та же — браузер изначально работает с URL, что позволяет делать вот такие штуки:

import confetti from 'https://cdn.skypack.dev/canvas-confetti';

Как вы понимаете, сделать такое с модульной системой Java или PHP нереально — потребуется пакет-менеджер, в то время как JS успешно работает вообще без него. Можете взглянуть на Deno для примера.

Сам вопрос интересный, но такой способ его не стала 2Я то э задать -- верный метод отхватить минусов и поднять вашу холивара!

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

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

MAM: сборка фронтенда без боли - это про автолоад на js/ts.

Инверсия контроля на голом TypeScript без боли - а тут ответ на главный вопрос вашей статьи.