Above is the result of running yarn start
react-scripts v2.1.0
I use the following code so I can use absolute paths in my TypeScript files, but everytime I run the yarn
command, everything gets blown out, and I can't run my project
"baseUrl": "./",
"paths": {
"src/*": [
"src/*"
]
}
Is there a way or could there be a way to opt out of react-scripts
auto-generating the tsconfig?
After further research, I can see this commit, which explains you do not support absolute path imports
https://github.com/facebook/create-react-app/commit/a95822451cf65c04bb00cde674ce48744ff444df
// We do not support absolute imports, though this may come as a future
// enhancement
baseUrl: {
value: undefined,
reason: 'absolute imports are not supported (yet)',
},
paths: { value: undefined, reason: 'aliased imports are not supported' },
}; };
But I was most certainly using absolute imports before this release went live, with the version of react-scripts that was on the master branch, so I'm curious how exactly it's not supported
The change is very recent: https://github.com/facebook/create-react-app/pull/5609. I had suggested elsewhere that value
should be suggested
, but that has been ignored so far.
That's....disappointing. I've used absolute paths very successfully in large scale TypeScript projects - not sure why such a rule would be enforced so heavy-handedly here.
These values are not supported and are no-op in Create React App. They are removed to prevent confusion and fix errors (so they show properly) in VSCode.
Aliasing paths is a foot gun and isn't of much value when using VSCode or an IDE. Absolute imports (baseUrl
) will be supported at a later date. Closing as a duplicate of #5118.
You can see a more detailed explanation here: https://github.com/facebook/create-react-app/issues/5585#issuecomment-433900655
Also, be sure to remove your exclude
property from tsconfig
-- it looks like you used the betas.
Just because you think something could potentially be confusing doesn't mean it's a good reason to actively block people who know what they are doing from being able to use it. There is no technical reason as to why this feature native to TypeScript should be restricted in CRA. I thought CRA as a project was looking to move away from enforcing opinionated decisions on it's users?
Aliasing paths is quite straightforward and is of great value even when using an IDE because you spend more time writing feature code and less time guessing how many ../
's you need on your import or waiting for your IDE's path autocomplete to show you still need to go up another directory for the module you're trying to import. Anyone looking to use aliases via TS paths should already be aware they'll need to also alias the paths for runtime (Babel module-resolver
plugin works great) so I don't see how it could even really be considered a footgun.
From what I can see it was restricted because CRA does not automatically handle aliases in paths
as per https://github.com/facebook/create-react-app/issues/5585. The thing is, handling aliases in paths
automatically from react-scripts
is not necessary for the feature of TypeScript to be usable or useful, as far as I know no other framework or "create" kit for other frameworks does this automatically out of the box, so considering it essential for paths support in CRA is silly. Just because CRA didn't do some voodoo magic that the opener of #5585 mistakenly expected to happen doesn't mean the ability to use it should be restricted for those of us who want and know how to.
To me the addition of this restriction without any way to opt-out is clearly a regression. The capabilities of CRA have been reduced to no tangible benefit.
I see some people are disappointed with some tsconfig restrictions.
While CRA doesn't change this internally, my short term recommendation is that you use patch-package and simply remove the restrictions from your react-scripts
verifyTypeScriptSetup.js file.
These days I don't stress at all when some lib doesn't do something I want, I just patch them using patch-package. Remember that CRA is an open source project, so you can change anything you want.
Most helpful comment
That's....disappointing. I've used absolute paths very successfully in large scale TypeScript projects - not sure why such a rule would be enforced so heavy-handedly here.