Skip to content
This repository has been archived by the owner on Jun 3, 2019. It is now read-only.

Support of absolute imports #203

Closed
kompot opened this issue Nov 29, 2016 · 7 comments
Closed

Support of absolute imports #203

kompot opened this issue Nov 29, 2016 · 7 comments

Comments

@kompot
Copy link

kompot commented Nov 29, 2016

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

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
Copy link
Owner

ctrlplusb commented Nov 29, 2016

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
Copy link
Owner

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

@kompot
Copy link
Author

kompot commented Nov 29, 2016

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
Copy link
Collaborator

enten commented Nov 29, 2016

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
Copy link
Collaborator

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

@ctrlplusb
Copy link
Owner

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

@kompot
Copy link
Author

kompot commented Dec 1, 2016

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants