Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[Request] Opt out of tsconfig automation #5625

Closed
martinmckenna opened this issue Oct 30, 2018 · 7 comments
Closed

[Request] Opt out of tsconfig automation #5625

martinmckenna opened this issue Oct 30, 2018 · 7 comments

Comments

@martinmckenna
Copy link

martinmckenna commented Oct 30, 2018

screen shot 2018-10-30 at 8 32 40 am

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?

@martinmckenna
Copy link
Author

martinmckenna commented Oct 30, 2018

After further research, I can see this commit, which explains you do not support absolute path imports

a958224

    // 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

@rassie
Copy link

rassie commented Oct 30, 2018

The change is very recent: #5609. I had suggested elsewhere that value should be suggested, but that has been ignored so far.

@martinmckenna
Copy link
Author

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.

@Timer
Copy link
Contributor

Timer commented Oct 30, 2018

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: #5585 (comment)

@Timer Timer closed this as completed Oct 30, 2018
@Timer
Copy link
Contributor

Timer commented Oct 30, 2018

Also, be sure to remove your exclude property from tsconfig -- it looks like you used the betas.

@wyqydsyq
Copy link

wyqydsyq commented Nov 23, 2018

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 #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.

@brunolemos
Copy link
Contributor

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.

@facebook facebook locked as too heated and limited conversation to collaborators Nov 27, 2018
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Projects
None yet
Development

No branches or pull requests

5 participants