add support for webpack alias

[xyy94813]

Cannot detect the imported file if a project not use relative path import.

For example, use babel-plugin-module-resolver:

// .babelrc
{
  "plugins": [
    [ "module-resolver", {
       "alias": {
          "@": "./src"
        }
     }]
  ]
}

or use webpack resolve. alias

module.exports = {
  //...
  resolve: {
    alias: {
      '@': path.resolve(__dirname, 'src')
    }
  }
};

[smeijer]

At the moment, only typescript aliases are supported. I think we can add support for webpack, but I'm not sure what to do with babel. Babel configs are highly dynamic.

An alternative would be to add support for specifying an mapping in .unimportedrc.json which would have a similar syntax to the typescript (tsconfig#paths) variant.

[xyy94813]

I'm a little confused as to why this is directly related to Webpack.

Isn't that what we need to do to find all imported files by parsing,
and compare them to the files in the directory?

It doesn't matter which way we use to set the alias in project.

[smeijer]

Node doesn't support something like import aliases, that's why you declare them in your webpack config. This project does read import aliases from tsconfig, but not from a webpack config. Hence, it doesn't resolve the aliased file paths.

It's not related to webpack itself. It's related to you using import aliases.

[Nantris]

@smeijer thanks for this great project! I wonder if there's some method I'm overlooking to deal with a situation like this:

We have a monorepo with a lot of shared code, and then some platform-specific code with package names like our-utils-platform - which will resolve to our-utils-web in Webpack and our-utils-react-native for React Native.

Is there any way to accommodate both of these circumstances with the current configuration capabilities? As it is right now, out-utils-platform can't be resolved by this tool. I see we could include an alias - but what about in a case where for different entry points, they need different aliases?

For web we use Webpack resolve, but for mobile we use Babel resolutions. I'd be happy to configure all the resolvers by hand if it seemed like there were a way with the current configs.

The only other option that occurs to me right now would be for us to make multiple .unimportedrc.json.platform files and dynamically make each one the active config as needed, but I'm hoping to avoid that.

Thank you again for this great project!

[Nantris]

With --show-config I see there's an entryFiles field with aliases beneath it. Is this a pattern we can use directly in our .unimportedrc.json? I'm guessing yes and working on that now.

Edit: Unless I'm doing something wrong, I guess we can't specify entryFiles directly?

#96

[smeijer]

Hi @slapbox , it is possible to specify entryFiles via the config file. Does that help?

{
  "entry": ["src/main.ts", "src/pages/**/*.{js,ts}"],
}

[Nantris]

Hey @smeijer, thanks for your reply!

What I mean is to allow resolutions to be set on a per-entry basis. So in your example, maybe entry[0] would need to resolve our-utils-platform to our-utils-node and in entry[1] would need to resolve our-utils-platform to our-utils-web.

It seems like unimported makes a configuration like that of its own behind the scenes that looks like below, and it would be great if we could set the same type of config from the .unimportedrc.json

"entryFiles": [
    {
      "file": "src/main.ts",
      "aliases": {
        "our-utils-platform": "our-utils-node
      },
      "extensions": [ ".js", ".ts", ".tsx" ]
    },
    {
      "file": "src/pages/**/*.{js,ts}",
      "aliases": {
        "our-utils-platform": "our-utils-web
      },
      "extensions": [ ".js", ".ts", ".tsx" ]
    },

Does that explanation make sense? Thanks again for your hard work and for your reply!