Maybe
react-scripts: 3.0.0-next.68
Your project's
baseUrl
can only be set tosrc
ornode_modules
. Create React App does not support other values at this time.
{
"compilerOptions": {
...,
"baseUrl": "."
},
}
Why is baseUrl
currently limited to src
or node_modules
?
Like the message says support for baseUrl
is currently limited to src
or node_modules
.
.
refers to the project root which is neither of the supported options.
I think the question was about why the support is limited to these values. Seems like a legit question.
Support for aliases in the roadmap, but importing files outside of src
and node_modules
has always been restricted in create-react-app
, therefore .
is not allowed.
We've limited baseUrl
to src
and node_modules
because that's what we were previously allowing with NODE_PATH
. I think once we add support for aliases we might want to reconsider this restriction.
I think setting the base url to "." is safer than setting it to "src".
Imagine you have a file like named "src/react/index.js/ts" (or named like some other famous library) for some reason
By setting the baseUrl to "src" you'd need to do import ... from "react"
, which might lead to confusion.
If the baseUrl is set to '.' it would be import ... from "src/react"
, which is less confusing and less likely to have name clashing.
Fair point, but the downside is that it can cause confusion making people think you can import source files from outside src
.
In my opinion aliases are a better way to safeguard your project against the problem you are describing.
I am one of those who were using NODE_PATH=./
with 2.x just to be able to prefix my own absolute imports with src
:
import bar from 'foo/bar'; // this is a node_modules import
import baz from 'src/baz'; // this is definitely an import from my own code because it starts with src
import styles from 'src/styles/foo.scss'; // also from my own code
I understand why you made this change but the truth is that NODE_PATH=./
used to work in 2.x and now it's not only deprecated but it also stopped working (with .
I mean).
I am pretty reluctant to switch to baseUrl=src
- it would mean my imports would be all over the place: from 'baz'
from 'components/..'
from 'shapes/..'
from 'styles/...'
from 'utils/...'
So my question is: is there a way to keep my imports with src with the current CRA 3 (without ejecting)?
Will aliases solve this problem if not? Are aliases close if so? Can I help speed things up if not? :)
I have to take the workaround:
.env
file to please create-react-app{
"compilerOptions": {
"baseUrl": "."
}
}
"extends": "./paths.json"
to prevent create-react-app overwrite tsconfig.json, also for vscode auto-import and resolve work properlyWaiting for cra aliases or tsconfig paths supported
I have to take the workaround:
_ugly workaround_
@rovansteen, as the fine engineer I'm sure you are ... aren't you _offended_ on some level that people are having to resort to this? I don't really mean _offended_, but In the way that all good engineers are offended by bad solutions when a good one is possible (even if the bad ones aren't that much harder)?
Don't you _want_ developers preventing issues such as Bob creating src/lodash
to hold his Lodash-based utility functions (and now none of the lodash imports are working)? Clearly setting the root above src, even with some kind of limitation to only allow importing from src ... prevents such cases (unless you npm i src
... if such a package even exists).
Couldn't any sort of pre-alias solution, like allowing a third valid baseUrl
choice of ".
", but then restricting all imports to "./src
", be reasonable (or _maybe_ allow ./test
also, because it's a popular convention to have a test
mirror src
?)? That way you do _exactly_ what you're doing now, but instead of giving errors to everyone who uses ".
", you only do so to the subset that import "./somethingElse
".
P.S. The longer there's no solution, the more teams will just opt to use src
as their baseUrl
, instead of using @trungtin 's great solution, because it's easier to just do so. Then when Bob makes src/lodash
(or worse, some more obscure library that _doesn't_ break things in a nice obvious way), they'll lose however long it takes them to track down the problem ... all because they couldn't set baseUrl: "."
.
I think there is already protection in place against importing files outside of the src
directory so I鈥檓 not opposed to loosening the basePath config here as people should get a warning if they try to import from anywhere else.
Aliases turned out to be quite difficult to implement as the Typescript implementation is very different from Webpack. So if this would tackle the most requested need for aliases that might be a better option, at least for now. What do you think @iansu?
Setting baseUrl
to .
is supported now in v3.2.0
.
_Please note that there is still a limitation that you can only import files from src
, but you should be able to use the full path now (like src/components/Button.js
)._
Most helpful comment
I think setting the base url to "." is safer than setting it to "src".
Imagine you have a file like named "src/react/index.js/ts" (or named like some other famous library) for some reason
By setting the baseUrl to "src" you'd need to do
import ... from "react"
, which might lead to confusion.If the baseUrl is set to '.' it would be
import ... from "src/react"
, which is less confusing and less likely to have name clashing.