Alias paths are broken on Windows

[scott-cornwell]

"webpack": "^4.44.2",
"@linaria/babel-preset": "3.0.0-beta.2",
"@linaria/core": "3.0.0-beta.2",
"@linaria/react": "3.0.0-beta.2",
"@linaria/shaker": "3.0.0-beta.2",
"@linaria/webpack-loader": "3.0.0-beta.1",

node 14.15.5
Windows 10

Description

I'm defining webpack aliases like this:

_utils: path.resolve(__dirname, "src/utils/"),

The files that go through linaria loader don't handle paths right for Windows. The path to resolve to for the alias turns into a Windows path, but the part from the actual import, something like this:

import { responsive } from '_utils/responsive'

just gets concatenated with the alias path to something like this: My\Windows\Path\utils/responsive

I tried a lot of different versions of linaria packages and some other ways to try and rewrite these paths but nothing has worked.

[Anber]

Hi @scott-cornwell!

There are already a lot of issues about aliases (eg. #811, #658, #652, etc.). The only working solution right now is using babel-plugin-module-resolver.
The main problem with webpack aliases is that webpack resolver function is async whereas babel is completely synchronous, so we can't just use webpack/rollup resolvers. However, it looks like @layershifter has found a workaround that can possibly allow us to execute async resolvers in sync mode, but there are still a lot of work to implement that workaround.

[scott-cornwell]

I tried that but it's not working for me. It seems like somewhere along the line it's just not using the path module, because that should just take care of it. Also most versions of linaria don't even seem to work, I'm not sure what the problem is but it seems like the entire resolve object comes back as null in most other versions I try of the loader. Do you know where it actually concatenates the import path with the alias? That part should be using path and it should just work, I don't see how it has anything to do with sync/async.

Also I did see those other issues, but they are different. This is dealing specifically with Windows paths, which babel-plugin-module-resolver does not seem to fix.

[scott-cornwell]

I think I found where it happens, but it's in enhanced-resolve itself that is the problem. I have raised an issue there, I believe the problem is this line https://github.com/webpack/enhanced-resolve/blob/main/lib/AliasPlugin.js#L70

I'm trying to make my own modified AliasPlugin that is fixed but the plugin does not seem to get run. Hopefully they can fix it.

[scott-cornwell]

@Anber Ok I figured it out, actually it works it's just very confusing to set up. I had to define my aliases twice, once for webpack resolve with absolute paths, and once for babel-plugin-module-resolver for linaria with relative paths. Would be good to document how to actually use this with linaria!

In webpack resolve:

  resolve {
      extensions: [".js", ".jsx"],
      alias: {
        _utils: path.resolve(__dirname, "src/utils/"),
        _components: path.resolve(__dirname, "src/pages/"),
      }
  }

In linaria loader:

{ loader: '@linaria/webpack-loader',
  options: {
    sourceMap: true,
    displayName: true,
    babelOptions: {
      plugins: [
        ['babel-plugin-module-resolver', {
          extensions: ["*.js", "*.jsx"],
          root: "./src",
          alias:   {
            "_utils": "./src/utils/",
            "_components": "./src/components/",
          }
        }],
      ]
    }
  }
}

This allows me to have fully working aliases on Windows with Linaria!