baseUrl not support '.'

[xiaoxiangmoe]

Is this a bug report?

Maybe

Version:

react-scripts: 3.0.0-next.68

Error info:

Your project's baseUrl can only be set to src or node_modules. Create React App does not support other values at this time.

tsconfig

{
  "compilerOptions": {
    ...,
    "baseUrl": "."
  },
}

Question:

Why is baseUrl currently limited to src or node_modules?

[robertvansteen]

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.

[gaearon]

I think the question was about why the support is limited to these values. Seems like a legit question.

[robertvansteen]

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.

[iansu]

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.

[xaviergonz]

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.

[robertvansteen]

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.

[terebentina]

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? :)

[trungtin]

I have to take the workaround:

• keep using NODE_PATH=./ in .env file to please create-react-app
• create paths.json file with

{
  "compilerOptions": {
    "baseUrl": "."
  }
}

• and in tsconfig.json add "extends": "./paths.json" to prevent create-react-app overwrite tsconfig.json, also for vscode auto-import and resolve work properly

Waiting for cra aliases or tsconfig paths supported

[machineghost]

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: ".".

[robertvansteen]

I think there is already protection in place against importing files outside of the src directory so I’m 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?