Repository navigation
re:add src directory to webpack resolve.modules @next #4336
Description
This is meant as a follow-up to #3596, as I'm testing out the newest CRA alpha react-scripts 2.0.0-next.66cc7a90.
The new CRA has solved several of my common reasons for having to use react-app-rewired, but there are a few pain points that remain.
One of them is adding the top-level src to the webpack resolve path so all components can import paths relative to the src root as opposed to relative to the file itself. I find this to be cleaner and more descriptive. E.g., this:
import Foo from 'components/Foo'
import Bar from 'store/Bar'
import Util from 'lib/Util'instead of
import Foo from '../Foo'
import Bar from '../../store/Bar'
import Util from '../../lib/Util'I generally accomplish this via react-app-rewired:
module.exports = (config, env) => {
config.resolve.modules = [
path.join(__dirname, 'src')
].concat(config.resolve.modules)
return config
}But I figure this has to be a pretty common practice, and I don't really see any downsides to allowing this in the base CRA webpack config, so I thought I'd suggest it as a very minor change for CRA@next.
I know the current suggestion is to add NODE_PATH=src to .env (#3596) with #1333 tracking a more permanent solution, but as of the latest alpha, this functionality is still not working.
To be clear, I generally add this via react-app-rewired because relying on .env which I've relegated to containing secrets means that the project will no longer "just work" for other devs out of the box.
Activity
[-]re:add src directory to webpack resolve.modules[/-][+]re:add src directory to webpack resolve.modules react-scripts@next[/+][-]re:add src directory to webpack resolve.modules react-scripts@next[/-][+]re:add src directory to webpack resolve.modules @next[/+]zomars commentedon Apr 25, 2018
Thank you!
gaearon commentedon May 3, 2018
This sounds dangerous. You're aware that any "secrets" used in client-side code will be part of your JS bundle, right? So there shouldn't be anything really sensitive there.
This differs from Node resolution mechanism. It's a huge downside because then tools can't agree on how to resolve paths.
gaearon commentedon May 3, 2018
Can you elaborate on that? I think at least some support for Workspaces was merged although I don't remember how extensive it is.
transitive-bullshit commentedon May 3, 2018
Thanks for the response @gaearon!
Yes, I'm fully aware of this. What I meant was that outside of Facebook-land, you typically have multiple services (like an api sever), each potentially with their own
.env, and so treating some.envfiles as not secret and others as secret is a slippery slope, even though any frontend CRA.envfile's contents will of course be made public. This seems like a pedantic argument, though; I'm just not happy with the solution of requiring you to add something to.envin order to get a CRA app that would otherwise work out-of-the-box working.I can definitely understand this point, although you're not changing the Node resolution mechanism at all. By either appending to
NODE_PATHor using webpack'sresolve, you're just taking advantage of a built-in override.Sure -- I just mean that this specific functionality of importing from top-level
src/still isn't working with the latest alpha without one of the aforementioned workarounds.The second point (changing the resolution mechanism) is the biggest pushback here for sure. If you feel strongly about not disrupting things with this, I understand will close this issue. I do think it's a pretty common and expected style, however, with some clear semantic benefits, though I'm really not sure how to gauge interest on this type of thing aside from letting the issue remain and seeing if people upvote it.
Thanks again!
stale commentedon Nov 2, 2018
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 7 days if no further activity occurs.
Timer commentedon Nov 2, 2018
#5118