Оберните многие внутренние модули для экспорта в машинописный текст

Я рассматриваю использование машинописного текста в узле и в настоящее время привык использовать машинописный текст с помощью синтаксиса ///<reference.../> исключительно с использованием внутренних модулей. Однако с более крупными проектами это может стать громоздким, поскольку у вас могут быть модули, ссылающиеся на другие модули, которые имеют взаимосвязанные ссылки.

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

Таким образом, синтаксис будет очень похож на существующие узлы, требующие механизмов, например:

import database = require("my-external-db-module.ts");
var connection = new database.Connection(someUrl);

скорее, чем

///<reference path="my-internal-db-modules.ts" />
var connection = new Database.Connection(someUrl);

И я предполагаю, что синтаксис будет примерно таким:

///<reference path="all-my-internal-module-files-etc.ts" />
///<reference path="..." />
export module SomeExposingModule
{
   // Not quite sure what to put in here to expose the internal modules
}

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


node.js typescript amd
person Grofit    schedule 18.07.2013    source источник

Ответы (3)


arrow_upward
5
arrow_downward

Я не уверен, что это плохая практика или нет, но вот как я решил свою проблему.

Сначала краткое изложение проблемы:

У меня есть несколько файлов, логически сгруппированных в пространстве имен, например Framework, тогда все файлы в нем будут Framework.*, например Framework.Database или Framework.UnitOfWork. Затем все это скомпилировано с помощью tsc --out framework.js ..., поэтому я вывожу все это в файл framework.js.

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

// exporter.ts
module.exports = Framework;

Таким образом, при условии, что это последний файл, добавленный в компиляцию tsc, вы получите что-то вроде:

// Framework.js
var Framework;
(function (Framework) {
    // lots of good stuff
})(Framework || (Framework = {}));
module.exports = Framework;

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

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

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

var Framework = require("./framework");
var database = new Framework.Database.DbConnection();
person Grofit    schedule 31.07.2013
comment
В моем случае со сценарием сборки Unix мне было проще добиться того же результата с помощью следующей команды: echo 'module.exports = Framework;' ›› Framework.js - person David Leppik; 19.07.2014

arrow_upward
2
arrow_downward

Есть некоторые идеи, которые помогают сгладить некоторые из этих проблем.

Если у вас много ссылок, вы можете использовать файл ссылок для управления ими. Например:

ссылки.ts

///<reference path="a.ts" />
///<reference path="b.ts" />
///<reference path="c.ts" />
///<reference path="d.ts" />

Все остальные файлы...

///<reference path="references.ts" />

Теперь у вас есть центральный список ваших ссылок, что намного проще, чем сплетение списков ссылок вверху каждого файла.

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

person Fenton    schedule 18.07.2013
comment
Моя проблема заключается не столько в управлении ссылками, сколько в моем текущем проекте, я делаю, как вы говорите, и это работает ok, поэтому у меня есть куча файлов, разбросанных по всему проекту, и я использую скрипт сборки. для создания типов файлов поиска ссылок на уровне проекта. Проблема, с которой я сталкиваюсь при таком подходе, заключается в том, что если у меня есть проект базы данных и логический проект, который зависит от базы данных, используя описанный выше подход, мой скомпилированный файл logic.js содержит как содержимое файлов ts базы данных, так и файлы ts логики. , тогда как я надеюсь использовать внешние модули, чтобы избежать этой дополнительной компиляции болтовня - person Grofit; 18.07.2013
comment
Извините, что дважды публикую комментарии, но продолжу, поэтому, чтобы избежать эффекта снежного кома внутренних ///<reference/> включений, я надеялся в этом новом проекте принять внешние модули, чтобы logic.js содержал только скомпилированные js из файлов логики и просто ссылался другой модуль, создающий простую зависимость времени выполнения, а не время компиляции. Я упомянул проблемы вышеупомянутого подхода в вопросе, который я поднял с хорошими людьми, управляющими Typescript. typescript.codeplex.com/workitem/923 Я надеялся обойти проблему, описанную с внешними модулями. - person Grofit; 18.07.2013
comment
Да, в вашем случае я бы полностью посвятил себя загрузке внешних модулей по запросу, поскольку он опирается на встроенные функции NodeJS. - person Fenton; 18.07.2013

arrow_upward
1
arrow_downward

Что вы можете сделать, так это скомпилировать набор файлов TS в комбинацию .js + d.ts. например следующее создает out.js и out.d.ts

tsc a.ts b.ts --out mod.js --declaration

И тогда (надеюсь) сработает следующее:

///<reference path="mod.d.ts">
var mod = require('mod')
person basarat    schedule 18.07.2013
comment
Интересный момент, который вы поднимаете, я генерирую *.d.ts из моего текущего конвейера. Поэтому, если бы я просто скомпилировал их все как внутренние модули, то потребовал бы их через d.ts, что даст мне интеллектуальное понимание и безопасность времени компиляции, но я надеялся избежать использования синтаксиса ///<reference>. Однако я поиграю с этой идеей, так как это кажется лучше, если я могу потребовать файл d.ts в качестве экспортируемого модуля, а не писать оболочку для своих внутренних модулей. - person Grofit; 18.07.2013