AstroTurfLoaderError: Cannot use the decorators and decorators-legacy plugin together

[lithiumfallen]

I'm looking for css-in-js library for my project, linaria and astroturf are in my preference.
astroturf looks better for me because we already use css modules using .less.

The problem is when I use { legacy: true } for @babel/plugin-proposal-decorators build will crash with error message: AstroTurfLoaderError: Cannot use the decorators and decorators-legacy plugin together.

My babel config is:

{
    presets: [
        ['@babel/preset-env', {
            loose: true,
        }],
        '@babel/preset-react',
    ],
    plugins: [
        '@babel/plugin-syntax-dynamic-import',
        [
            '@babel/plugin-proposal-decorators',
            { legacy: true },
        ],
        '@babel/plugin-proposal-object-rest-spread',
        ['@babel/plugin-proposal-class-properties', { loose: true }],
        [
            '@babel/plugin-transform-runtime',
            {
                corejs: false,
                helpers: true,
                regenerator: true,
                useESModules: false,
            },
        ],
    ],
}

What i do wrong?

[jquense]

Looks like a bug. We add a bunch of default parser options to ensure files are parsed but those are conflicting with your local config

[chrisabrams]

I ran into the same issue here :O

[amokrushin]

There is conflict with project's babel.config.js. Can be solved with transformSync's option configFile: false in addition to babelrc: false

[jsg2021]

Adding configFile: false does indeed resolve this error, but this is configuring a stage-2 plugin... with decorator before-export enabled. This conflicts with the tc39's current consensus... this is just enabling the parsing of that syntax, why is it being opinionated? If we use the legacy version for syntax that allows for both, and we'd get by. I could offer a PR if that would be accepted.

[jquense]

It's not intentionally opinionated, the parser requires picking one. Last I tried the two options were not compatible with each other. If that's different now I'm certainly open to it

[jsg2021]

yeah, swap the
decoratorsBeforeExport:true with legacy:true and you will tolerate both. Since you're just parsing, the legacy path doesn't make a difference to you. (other than being permissive)

[jsg2021]

If you want, I can open a PR in the morning.

[jquense]

certainly open to it, but i'm still a bit skeptical since the new decorators spec had added different syntax like import @decorator from 'foo' that...tho it looks like as of 2 weeks ago that's not the case anymore??? This proposal is wild.

[jsg2021]

That decorator proposal never made it into babel, as far as I can tell. The decorator plugin only implements the original (legacy) and the revised proposal that only added a runtime. The static decorator proposal you are referring to has died. It's back to "decorators are functions"... very similar to the original (imo). ...and yes, that proposal is wild. Which actually makes me wonder if you should move to make this loader come after babel-loader so that you can avoid having to support unreleased proposals.

[jquense]

yeah having to guess at parsing config is super annoying, we could actually just defer to babel if there is a local config but it's a bit tricky to do, even tho babel exposes the right API's now for doing that.

you should move to make this loader come after babel-loader so that you can avoid having to support unreleased proposals.

That is perfectly reasonable btw, as long as your babel setup isn't compiling tagged template strings, something that is a lot more likely now than a few years ago

[jsg2021]

you should move to make this loader come after babel-loader so that you can avoid having to support unreleased proposals.

That is perfectly reasonable btw, as long as your babel setup isn't compiling tagged template strings, something that is a lot more likely now than a few years ago

Yeah, that could even be articulated in the setup for people targeting very old runtimes... or error at startup?

[jsg2021]

Yeah, that could even be articulated in the setup for people targeting very old runtimes... or error at startup?

Nevermind, this loader doesn't transform the tag template literals... yeah, it's better to just ensure the parser can at least handle tags and let the user's config fill in the rest.