Сохранение метаданных с помощью Typescript, Babel 7, декораторов

К сожалению, я достаточно уверен, что это ограничение использования Babel с Typescript. Что делает Babel, так это просто убирает типизацию машинописного текста, а затем обрабатывает код как JavaScript. Это означает, что babel не заботится о вашем tsconfig.jsonвообще, а значит, и о emitDecoratorMetadata.

Так что, к сожалению, если вам нужны метаданные декоратора, вам придется придерживаться tsc.

По умолчанию это не поддерживается, как указано в другом ответе. Однако мы можем написать плагин babel, чтобы заставить его работать.

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

Ограничения:

• Если аннотации типа нет, у нас нет типа для записи
• Если у нас есть ссылка на тип, мы можем использовать только имя типа, мы не можем проверить, относится ли ссылка к интерфейсу, как псевдоним типа, класс или перечисление. На практике это означает, что:
  • Если тип является интерфейсом или псевдонимом типа, имя типа будет undefined во время выполнения, чтобы избежать неопределенного, мы можем сделать type || Object по умолчанию для объекта, если тип не имеет связанного значения времени выполнения.
  • Если тип является перечислением, Typescript будет записывать Number или String в метаданные, в зависимости от типа перечисления. Поскольку мы записываем имя типа в метаданные, это означает, что вы получите объект-контейнер перечисления внутри метаданных.

Сериализация типов может быть скопирована из самого компилятора машинописного текста с минимальными изменениями (а на самом деле это всего две функции serializeTypeNode и serializeTypeList, всего около 150 строк кода).

Для этого примера класса мы получаем следующие результаты:

declare var decorator: any;

interface ISampleInterface {

}

enum Flags { One }
class OtherClass {}


type ArrayAlias = number[]

class Test {
    @decorator
    untypedProp; // no design:type
    @decorator
    nrProp: number // Number as expected
    @decorator
    strProp: string // String as expected
    @decorator
    boolProp: boolean // Boolean as expected

    @decorator
    nrPropUndefined: number | undefined // Number as expected
    @decorator
    strPropUndefined: string | undefined // String as expected
    @decorator
    boolPropUndefined: boolean | undefined // Boolean as expected

    @decorator
    arrayProp: number[]

    // Type references
    @decorator
    classRefProp: OtherClass; // OtherClass || Object  = Object since OtherClass is still a class at runtime

    @decorator
    interfaceRefProp: ISampleInterface;  // ISampleInterface || Object  = Object since ISampleInterface is undefined at runtime

    @decorator
    enumRefProp: Flags; // Flags || Object = Flags since Flags exists as a value at runtime, here TS would have written Number/String

    @decorator
    typeAliasProp: ArrayAlias; // ArrayAlias || Object = Object since ArrayAlias does not exist t runtime and in Babel swe have no idea ArrayAlias is actually an array

    @decorator
    selfClassRefProp: Test; // Test || Object  = Object since Babel puts decorators instantiation before class definition, this is a quirk, this may be fixable
}

Фактический код плагина не очень большой (за вычетом методов, скопированных из версии TS):

export default declare((api: typeof import('@babel/core'), { jsxPragma = "React" }): PluginObj => {
  api.assertVersion(7);

  return {
    name: "transform-typescript-decorator-metadata",
    inherits: syntaxTypeScript,

    visitor: {
      ClassDeclaration(path) {
        var node = path.node;
        for (const field of node.body.body) {
          if (field.type !== "ClassProperty") continue;

          if (field.typeAnnotation && field.typeAnnotation.type === "TSTypeAnnotation" && field.decorators && field.decorators.length > 0) {
            const key = field.key as t.Identifier;
            const serializedType = serializeTypeNode(field.typeAnnotation.typeAnnotation);
            field.decorators.push(decorator(
              t.callExpression(
                t.memberExpression(t.identifier("Reflect"), t.identifier("metadata")), [
                  t.stringLiteral("design:type"),
                  t.logicalExpression("||", serializedType, createIdentifier("Object"))
                ])
            ))
          }
        }
      },
    }
  };
});

Вы можете найти полный код плагина и рабочий образец здесь

С другой стороны, порядок плагинов имеет значение. Если @babel/plugin-proposal-class-properties появится перед нашим плагином, он сотрет все свойства, и у нашего плагина больше не будет информации для генерации декораторов. Это .babelrc, с которым я тестировал, и он работает, мне не удалось его использовать с какой-либо другой конфигурацией (но я не могу сказать, что я так старался)

  {
    "env": {},
    "ignore": [],
    "plugins": [
      "../plugin/plugin.js",
      ["@babel/plugin-proposal-decorators", { "legacy": true }],
      ["@babel/plugin-proposal-class-properties", { "loose": true }],
      "babel-plugin-transform-es2015-modules-commonjs"
    ],
    "presets": [
      "@babel/preset-typescript"
    ]
  }