Support of absolute imports

[kompot]

There are numerous approaches to get absolute paths and get rid of ../../../ hell.

• put everything under node_modules subfolder
• use symlinks
• use webpacks aliases
• use babel plugin (https://github.com/tleunen/babel-plugin-module-resolver)
• use lerna (https://lernajs.io/)
• use some kind of copy-on-change technique (like wix's wml https://github.com/wix/wml)

I know that lots of people think the problem is not that important. I'm not one of them :)

There are some long discussions to dive deeper into the problem (like this one in create-react-app facebook/create-react-app#1065).

I really like [and been using] the last approach — it's not that clean but it:

• just works (c) on any platform
• does not force you to use any specific project layout
• does not require special tooling support as every node tool supports node_modules.

What do you think?

[ctrlplusb]

I love the clean paths, but my concern is that it destroys IDE tooling. For example clickthrough, type inference systems, and code refactoring tools all depend on proper paths to be able to work correctly. Some of these tools are really powerful and helpful in my opinion.

I used to use babel-plugin-module-resolver but then decided to revert back to support tooling. Ever since I have been using IDE plugins that automatically put the relative path to a module in for me. Since I started doing this I no longer see the paths as anything but an aesthetic issue.

If you know of a solution which doesn't interrupt tooling I would be up for it.

[ctrlplusb]

Just seen that the nide_modules approach could support this. Interesting...

[kompot]

Yep, src/node_modules seems an ok solution. But it does not help when you have multiple submodules on various nesting levels. We are using wml to share code between react native project and plain-old react project. Clickthrough will work with it but you'll go to a copied to node_modules file so code refactoring is a no-go. That's true.

[enten]

Isn't it better to let the developer choose how to manage aliases?
Because that can be source of issues and wasted time for developer which hasn't noticed them.

Be careful to doesn't turn react-universally into a pseudo-strict framework where removing a little part breaks the rest.

Update:
In that case, if RU's v11 will released with that kind of alias configuration: remove it will break all imports

[codepunkt]

I would leave this up to the developer. You can't (and shouldn't) tackle every problem.

[ctrlplusb]

I am tending to agree with @code-punkt et al. on this. Going to close this for now.

[kompot]

You are the boss. Keep up great work with this project)