Published node module not ES5

[jasperkuperus]

Environment

• Linaria version: 3.0.0-beta.1
• Bundler (+ version): Webpack 5.26.0
• Node.js version: 12.16.2
• OS: macOS

Description

First off, I really like this lib. Keep up the good work.

The version of linaria that's published to npm isn't transpiled down to ES5 properly. I noticed due to spread operators, originating from @linaria/core, landing in my bundle.js that made older browsers crash. I guess the module should be properly transpiled to ES5 before publishing it to npm.

While investigating, I noticed that I was on this 3.0.0 beta. So I figured to downgrade to 2.1.0, which I saw in the releases. But it didn't allow me... Must be some renamed packages? Couldn't find any instructions on this. -> I managed to get 2.1.0 installed, but same issue there with spread operators in published package.

Reproducible Demo

n/a

[Anber]

Hi @jasperkuperus!

Fixed and will be released in 3.0.0-beta.2

[jasperkuperus]

Hi @Anber . Thanks for the quick reply! It looks like the spread operators are gone indeed. But now I'm running into the same issue with arrow functions:

This unfortunately also lets my older browsers crash :( Can we reopen this?

[Anber]

Ouch!
I completely forgot that there are browsers without the support of arrow functions :)

[Anber]

btw, do you know that property-based interpolation for styled is not working in such old browsers? You still can use css and styled, but property-based interpolation requires css variables.

[jasperkuperus]

Yes, I'm well aware. I think I can get away with that and for these browsers I aim for graceful degradation. Some styling that didn't get picked up by the browser is OK, but the app crashing is not 😊

[Anber]

Ok! I'll release a fix in a couple of days.

[jasperkuperus]

Perfect, again thanks for the fast/adequate response! Please keep me posted on when you publish it!

[Anber]

In order to avoid future reopenings, could you please replace these files in your local node_modules and confirm, that everything is ok? :)

• https://gist.github.com/Anber/77ecc5ff3c49032000eed8264516f244
• https://gist.github.com/Anber/540ac5a326fb900f1dd75089f2339a90
• https://gist.github.com/Anber/492f23973bc65c8214cc4466a044a084

[jasperkuperus]

Still has the same issue. So, as I've set webpack to target: es5, it apparently picks up the source code from core/esm, which still has arrow functions.

Quick and maybe silly question. Why not add a transpiler like Babel and make sure it transpiles the code before publishing it? That way you can keep using your favourite language constructs and users of the library are free to use it in any environment. And more importantly, if you forget to take this into account one day and accidentally write an arrow function, you won't break anyone's app 😊

[Anber]

It's transpilled: to es3 in lib and to es5 in esm. If you set webpack target to es5, webpack takes es5 version of code with arrows, const and imports/exports. However, there was a problem with the compilation target in babel, which excludes ie11, and the code itself has a few functions that weren't implemented in IE11. I hope, that #750 fixes it.

[jasperkuperus]

Ah, pardon me for thinking it's not transpiled. I'll be happy to test it when it's published!

[jasperkuperus]

@Anber When are you going to publish this to npm? I'd like to test it 😊

[Anber]

@jasperkuperus done!

[jasperkuperus]

It's transpilled: to es3 in lib and to es5 in esm. If you set webpack target to es5, webpack takes es5 version of code with arrows, const and imports/exports. However, there was a problem with the compilation target in babel, which excludes ie11, and the code itself has a few functions that weren't implemented in IE11. I hope, that #750 fixes it.

Tested 3.0.0-beta.3, it still picked up esm/. But considering your quote here, I forced Webpack to pick up lib/ and that fixed all my issues. No clue if this is the proper way to force loading lib/ in stead of esm/, but I ended up doing this:

  resolve: {
    alias: {
      '@linaria/core': path.join(__dirname, './node_modules/@linaria/core/lib'),
    },
  },

So consindering your intended approach @Anber , of having es3 in lib/, this issue is fixed 😊 Thanks a lot!

[Anber]

Hi @jasperkuperus!

Take a look at that config option https://webpack.js.org/configuration/resolve/#resolvemainfields
If you want to support old browsers, you probably need to specify main as a first option.

[jasperkuperus]

I considered, but that would make the switch on all my libraries, but at this moment only linaria was an issue for me. I might have to go down that path one day though. Thanks!

…

Sent from my iPhone

On 24 Apr 2021, at 14:46, Anton Evzhakov ***@***.***> wrote:  Hi @jasperkuperus! Take a look at that config option https://webpack.js.org/configuration/resolve/#resolvemainfields If you want to support old browsers, you probably need to specify main as a first option. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.