Alias output wrong

[amirmohsen]

I have an alias like this:

{
	"@namespace/package": "@namespace/package/client"
}

but this generates an incorrect alias and as a result throws this error:

Error: Cannot find module '@namespace/package/client/client'

Am I doing something wrong? Does this plugin have issues with namespaces? Not sure why I am getting two client parts in my path.

[fatfisz]

Hi @amirmohsen, I'm fairly certain that this happens because for some reason the plugin is applied two times, hence @namespace/package becomes @namespace/package/client and then in turn it becomes @namespace/package/client/client.

To solve this, either ensure that the plugin is only applied once or change the configuration so that @namespace/package will not be a prefix of what you're aliasing to (as is the case with @namespace/package/client).

If you can use JS config, you could have an alias like this:

{
  "@namespace/package": require.resolve("@namespace/package/client")
}

The plugin should ignore the absolute path that is the result of require.resolve and so won't be applied the second time.

@tleunen related: #176.

[tleunen]

Hmm.. Indeed, it seems the path resolution is applied twice.
@fatfisz Should we introduce the concept again of a node we already visit for the resolution?
Similar to this: https://github.com/tleunen/babel-plugin-module-resolver/blob/v2.7.0/src/index.js#L70-L72

[fatfisz]

We have to remember about a problem from the past: even if we mark the node, there is a possibility of another plugin replacing it with another and module-resolver being applied again. Scenario:

1. module-resolver is applied, import node is transformed and marked
2. transform-es2015-modules-commonjs is applied, import is transformed to require, marking is lost
3. module-resolver is applied again, require node is transformed and marked

This was fixed as it was fairly a common problem; whatever solution we come up with, it would be good not to revert this.

[amirmohsen]

@fatfisz thanks for the tip on using require.resolve. With that, it works well now.

In terms of why I have multiple copies of the plugin, it's because I'm developing several packages alongside my app and they are all symlinked. Each one of the packages and the app itself is compiled separately and has its own dev dependencies. This plugin along with a long list of other webpack and babel plugins are repeatedly installed in each folder. As a result, I have multiple copies of the same packages (such as this one).

[tleunen]

@amirmohsen But each packages should provide a "compiled" version of the code, with the relative path instead of the dev version using alias. Isn't it the case for you?

[amirmohsen]

As mentioned in my last comment, I have managed to get your plugin working now thanks to the tip from @fatfisz. However, it would be nice if this issue could be mitigated at the plugin-level or at the very least, if you could include a gotcha entry in your readme.md for other people.

@tleunen, since you asked, I'm gonna elaborate on my usecase below to help you understand why I have duplicate versions of the plugin and how I am utilizing it in my specific scenario which could be different from how most people may be using it. Apologies if it's a bit long-winded.

I am developing a universal modular web application which consists of a core and several namespaced packages (currently private, some may be open-sourced down the line). Each package does provide 2 "compiled" outputs, one for server and one for client. There are two reasons for this. The server code is compiled using Node 6 (soon to be upgraded to 8) babel preset and (and with webpack settings that are specific for Node) while the client code uses the env babel preset for browsers. Moreover, there are parts of the code that are meant only for client (dom-related) or only for server (db, etc). This is the case across all the packages as well as core. To get a better understanding, here's the simplified structure of my setup:

• Project
  • App (Core)
    • src
      • mixed server, client and shared files
    • dist
      • server
        • index.js
        • index.js.map
      • client
        • index.js
        • index.js.map
    • server.js // re-exports dist/server/index.js (using module.exports)
    • client.js // re-exports dist/client/index.js (using module.exports)
    • node_modules
      • @namespace
        • package-a
        • package-b
        • package-c
        • ... and so on (all internal packages are symlinked during dev)
  • Packages
    • Each package has the same structure as core. (i.e. two client and server entry points, etc)
    • Packages do rely on one another as well (peer dependencies)

So whenever I need to import a package whether it's in core or in another package, I want to use the compiled version that is appropriate for my current environment.

So instead of writing @namespace/package/server or @namespace/package/client, I want to write @namespace/package. As well as being more convenient, in some circumstances, this is essential such as shared code (React, schemas, utils, validators, etc) that runs both on the server and on the client.

Each package is compiled separately, has its own copy of dev dependencies and runs a separate webpack process. As I mentioned, the duplicate package issue happens during development due to symlinks. This is not an issue on production as packages are compiled pre-release (private npm registry) and the app itself is compiled pre-deployment.

Originally, I tried using webpack's alias feature to acheive what I needed, but it looks like that feature is completely broken! I even posted a question on SO about webpack aliases but no body could help. So I've been looking for alternatives and I found your package (Thanks!) as a solution.

[fatfisz]

@amirmohsen Hmm if it's only that, wouldn't that work perfectly?

{
  "^@namespace/package$": "\\0/server"
}

The problem is made bigger when you want to turn paths like @namespace/package/* into @namespace/package/server/* - but this is also solvable with a RegExp:

{
  "^(@namespace/package)(?!/server)(.*)$": "\\1/server\\2"
}

Those ideas came to me today, sorry you had to use the require.resolve hack 😞

@tleunen Of course this doesn't solve all of the problems that come from having cycles in the alias config. I think that we could try going back to node.seen - the plugin now is running before everything else (unless there's a plugin that is defined before it). There shouldn't be conflicts with transform-es2015-modules-commonjs, because it runs on Program:exit. I'll work on reintroducing node.seen today.

[tleunen]

Closing because of inactivity