How do I use babel for decorators instead of TS?

Question

This part of the documentation says that typescript is used for TS-specific features…

Removing TypeScript-specific features such as types, type-only imports, enums, and TypeScript decorators.

but decorators are not TS-specific.

TS decorators are different from the @babel/plugin-proposal-decorators output – how can I use this babel plugin for decorators instead of TS (forcing a tslib dependency, which I don’t want 😅 )

My babel config:

'use strict';

const { resolve } = require;

module.exports = {
  plugins: [
    [
      resolve('@babel/plugin-transform-typescript'),
      {
        allowDeclareFields: true,
        onlyRemoveTypeImports: true,
        optimizeConstEnums: true,
      },
    ],
    [
      resolve('@babel/plugin-proposal-decorators'),
      {
        legacy: true,
      },
    ],
    [
      resolve('@babel/plugin-proposal-class-properties'),
      {
        // loose: true,
      },
    ],
  ],
};

my ts setup:

    ts({
      transpiler: 'babel',
      browserslist: ['last 2 firefox versions', 'last 2 chrome versions'],
      tsconfig: {
        fileName: 'tsconfig.json',
        hook: (config) => ({
          ...config,
          declaration: true,
          declarationMap: true,
          declarationDir: './dist',
          removeComments: false,
        }),
      },
    }),

[wessberg]

If we do it like that, then we will have to add @babel/preset-typescript as an (optional) peer dependency, since otherwise just selecting transpiler: "babel" in the plugin config would lead to crashes, as the syntax wouldn’t be supported.

I’m very much in agreement with you generally in terms of magic. For rollup-plugin-ts, there is quite a bit of magic in place here, which historically has been a key reason why this plugin has tended to “just work”, where it has been a battle to configure everything correctly with other solutions. For example, if @babel/plugin-transform-runtime is found in the combined babel config, some options are forced on it such as to use ES modules and to import helpers instead of inline them to ensure that it plays nice with Rollup that will ultimately inline them (unless marked as external in the Rollup config), which builds up an internal module dependency graph of ES modules, as well as to let Rollup potentially code split the usage of helpers and avoid redundancy.

In terms of the “good, but overridable defaults” principle, in practice here what tends to happen is that people bring in their babel configs from other projects, and these very often come with configuration options that simply won’t produce great Rollup bundles. And instead of writing a ton of documentation of best practices and which options to disable when combining with Rollup, it has been a good solution to forcefully ignore some of those options that simply don’t play work well with this integration.

There are other examples of magic too, such as splitting babel configs into two if babel-minify plugins are identified, to ensure that the minification related plugins only run once per chunk, whereas others run once per file. All this to say that where I tend to do the opposite with other libraries, with rollup-plugin-ts I’ve always been hesitant to add config options if I can come up with a solution that “just works”, even if it means breaking transparency at times. I believe that’s what keeps this library’s promise of just working with absolutely no config options given intact, even if there’s some Babel, tsconfig, or swc config files in the root of the directory that may come with options that could otherwise be problematic.

Okay, sorry for the wall of text there. But that’s the context. I’m still fairly sure I would prefer a default behavior of only doing the full emit with Babel if I can find @babel/preset-typescript in the babel config, as I feel like that principle has worked well for this plugin in the past, but I’m also open for letting users explicitly decide this behavior with a config option. In that case, I’m thinking of extending the transpiler option like this:

// It can be a string
{
    transpiler: "babel"
}

// But it can also be a record
{
    transpiler: { 
        typescriptSyntax: "typescript",
        otherSyntax: "babel"
    }
}

With that option, we’re back to fully allowing customizing the transpilation behavior, while still retaining good defaults and respecting the input babel/swc configs as much as possible while still ignoring the ones that could break Rollup or produce inefficient bundles.

How does that sound?

[wessberg]

Hi there @chriskrycho.

I guess it would make sense to support delegating the full responsibility of syntax transformation to whatever transpiler has been chosen, such as babel. It could lead to some performance gains, albeit minor, since a TypeScript builder program would still be constructed based on the source file(s), since it is needed not just for diagnostics, but especially so for declaration files (which too need a proper type checker for the relationships between TS symbols to be correct in the declaration bundling phase).

In fact, I can see some value in not even exposing this as a config option, but enabling this behavior by default if @babel/preset-typescript can be found inside the combined Babel config, as that signals an intent from the library consumer to delegate the full responsibility to Babel. This is, of course, “magic”, which has downsides as well, such as less transparency. On the other hand, this library has always been about making things “just work” with minimal to absolutely no configuration, and I’m trying to stick to that philosophy. Of course, for some users, doing the first emit with the TypeScript Compiler APIs will have some advantages, but in these cases these users can just leave out @babel/preset-typescript from their babel configs.

What do you think about a solution such as this one?