Unexpected identifier? about gatsby-plugin-linaria HOT 21 CLOSED

@jazevedo620 @deklanw @silvenon @sslotsky

This has been fixed in v2.1.0. Please reopen the If it doesn't work for you

from gatsby-plugin-linaria.

I investigated for hours and found that it was a webpack setup problem with gatsby. The problem will only happen with <Link/> components of gatsby or @reach/router and others will be fine.

in detail:

GatsbyJS provide an alias for @reach/router when stage is about web: https://github.com/gatsbyjs/gatsby/blob/8d66161e4b/packages/gatsby/src/utils/webpack.config.js#L405

So the result of require(@reach/router) is resolved as es module which is linaria evaluator can't understand.

Linaria loader uses it here: https://github.com/callstack/linaria/blob/0ddfc9bb8eba99fe7e0b54790b5cf47493e207ea/src/loader.js#L43

That's why there is import React from "react"; unexpected identifier.

We should find some way to make linaria ignore the alias or to make linaria understand es module syntax.

from gatsby-plugin-linaria.

Brainstorming: one way could be to create a Babel plugin that transforms require('@reach/router') into something synonymous that wouldn't be caught by the alias, and pass it to Linaria loader?

@silvenon I just have done PoC of your idea. It would require two fixes:

1. replace @reach/router into @reach/router$ (exact match alias) in the webpack config.
2. Make plugin transforms require('@reach/router') into require('@reach/router/index.js') and give it babelOptions of linaria loader.

const config = getConfig();
const routerAlias = config.resolve.alias['@reach/router'];
if (routerAlias) {
  delete config.resolve.alias['@reach/router'];
  config.resolve.alias['@reach/router$'] = routerAlias;
}
replaceWebpackConfig(config);

Little hacky, but It would work without touching gatsby and linaria.

Since the @reach/router's es package is completely separate, we can be sure that direct references to index.js always want the commonjs module.

from gatsby-plugin-linaria.

Ok, I wrote almost all of the code, but I later realized that transformation only happens once and babel plugin cannot be affected during evaluating.

require('@reach/router') is indirectly called by gatsby or gatsby-link, so it's cannot be changed with the custom babel plugin.

Another similar version is:

1. Replace @reach/router into @reach/router$ (exact match alias) in the webpack config.
2. Make custom gatsby-link that directly use @reach/router/index.js
3. Make babel plugin to transform Link from gatsby or gatsby-link to our custom link

probably this version would work...

from gatsby-plugin-linaria.

Or just do forgery the linaria package on postinstall of gatsby-plugin-linaria?

What do you mean by this?

Just like callstack/linaria#392 (comment), we can use plugin's postinstall script to change linaria's behavior.

from gatsby-plugin-linaria.

Running into this issue as well. I see it's been a while since last activity here. Any chance of some progress on this? 🙏

from gatsby-plugin-linaria.

Heyo! I'll check this out tomorrow, thanks for pinging 😉

from gatsby-plugin-linaria.

Just letting everyone here know that this plugin is now under new ownership 🎉 @cometkim always had a better grip of the issues than me 😃

@cometkim considering that you have a better insight into what's going on here, could you take over?

from gatsby-plugin-linaria.

Hey folks, looks like this is breaking Gatsby v3, as they've vendored @reach/router and rely on that alias to resolve exisitng imports (even internal).

from gatsby-plugin-linaria.

This error isn't related to TypeScript, it's caused by specifically wrapping Gatsby's Link with styled. I'm not sure why this component in particular is problematic.

from gatsby-plugin-linaria.

Omg! 😵 Thanks! ❤️

Brainstorming: one way could be to create a Babel plugin that transforms require('@reach/router') into something synonymous that wouldn't be caught by the alias, and pass it to Linaria loader?

from gatsby-plugin-linaria.

Or just do forgery the linaria package on postinstall of gatsby-plugin-linaria? This is the simplest way I have right now Haha...

from gatsby-plugin-linaria.

Or just do forgery the linaria package on postinstall of gatsby-plugin-linaria?

What do you mean by this?

from gatsby-plugin-linaria.

The idea with the custom gatsby-link sounds like a more stable hack. Changing Linaria's behavior would break as soon as that code changes, if I understood correctly.

from gatsby-plugin-linaria.

Are there any working fixes/workarounds for this issue?

from gatsby-plugin-linaria.

Until I figure out a fix, a workaround is to simply wrap Link before styling it:

import { Link as GatsbyLink } from 'gatsby'
import { styled } from 'linaria/react'

const WrappedLink = (props) => <GatsbyLink {...props} />

const Link = styled(WrappedLink)`
  /* your styles */
`

I'll add this to the docs.

from gatsby-plugin-linaria.

Ok, workaround documented under "Known issues".

Now the error says SyntaxError: Cannot use import statement outside a module so that's how I wrote it down.

from gatsby-plugin-linaria.

This workaround doesn't seem to work for me; if I have any component inside of styled(...) that includes an import to { Link } from "gatsby" or anything from "@reach/router" at any point in its downstream import graph (regardless of whether the Link is wrapped with a passthrough component or not), the build will fail with the syntax error.

So far, the only working temporary fix I have found is to be cognizant of which paths of my file tree end up referencing Link or some other Router API (such as useLocation) at some point and never use them in a styled(...) clause. Instead, I can use the traditional const c = css... and set the className explicitly.

from gatsby-plugin-linaria.

This happened because of the linaria's extractor doesn't understand the esmodule syntax.

Removing the forced alias for @reach/router from the Gatsby's Webpack settings will make this work and Webpack still resolves esmodule anyway.

I'm curious why that alias was needed in the first place.

from gatsby-plugin-linaria.

related with gatsbyjs/gatsby#13197

from gatsby-plugin-linaria.

Thanks for the fix!

There is yet another error with the latest alpha [email protected], but with 2.0.0-alpha.4 everything is OK.

Update: the error is related to styled(Link) usage only

from gatsby-plugin-linaria.