TypeScript {paths} are not taken into consideration

[rolandjitsu]

Edit from maintainers: we want to support this — see #5585 (comment) for details!

---

Is this a bug report?

Yes.

Did you try recovering your dependencies?

NPM 5.6.0
Yarn 1.7.0

Which terms did you search for in User Guide?

paths, paths map, path mappings, typescript path, typescript paths

Environment

  System:
    OS: macOS High Sierra 10.13.6
    CPU: x64 Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz
  Binaries:
    Node: 8.11.2 - ~/.nvm/versions/node/v8.11.2/bin/node
    Yarn: 1.7.0 - ~/.yarn/bin/yarn
    npm: 5.6.0 - ~/.nvm/versions/node/v8.11.2/bin/npm
  Browsers:
    Chrome: 69.0.3497.100
    Firefox: 61.0.1
    Safari: 12.0
  npmPackages:
    @types/react: ^16.4.18 => 16.4.18 
    react: ^16.6.0 => 16.6.0 
    react-dom: ^16.6.0 => 16.6.0 
    react-scripts: 2.0.6-next.c662dfb0

Steps to Reproduce

TypeScript {paths} in {compilerOptions} are not working.

1. Clone cra-workspaces#cra-2
2. yarn install at the root
3. cd apps/cra
4. yarn start

Expected Behavior

CRA should resolve the modules listed in {paths}.

Actual Behavior

CRA cannot resolve the modules listed in {paths}.

Reproducible Demo

cra-workspaces#cra-2, instructions listed above.

[miraage]

AFAIK @babel/plugin-typescript only used for type-checking and validation, whilst actual emit is made by Babel (so no tsc is involved).

Adding tsconfig-paths-webpack-plugin should solve this issue.

[rolandjitsu]

@miraage but this would have to be done by CRA, because I'd like to avoid ejecting the config.

[miraage]

@rolandjitsu Agree. It should have been done by CRA, if I had been right in my assumptions regarding babel/tsc.

[rolandjitsu]

@miraage actually, @babel/plugin-typescript loads @babel/plugin-transform-typescript which does the opposite of what you describe, it does not type check, it just transforms the ts to js.

So it's possible that path support needs to be added in both webpack and babel. Furthermore, jest also needs support for this (in react-scripts-ts this is done via jest moduleNameMapper option).

[miraage]

@rolandjitsu

https://babeljs.io/blog/2018/08/27/7.0.0#typescript-support-babel-preset-typescript

We worked with the TypeScript team on getting Babel to parse/transform type syntax with @babel/preset-typescript, similar to how we handle Flow with @babel/preset-flow.

[Timer]

Currently this is done on purpose. We have no immediate plans to respect alternate module resolve modes/paths.

[lee-reinhardt]

EDIT: This workaround no longer works with the latest CRA versions where the TS config is routinely reset.

This can be achieved without ejecting if you're willing to use react-app-rewired in combination with customize-cra.

There's a big warning on the react-app-rewired readme about it not supporting CRA 2.x, but this is referring to their helpers like injectBabelPlugin and such. The base machinery for allowing you to hook into and override Webpack/Babel configs is still useful. The actual Webpack/Babel config manipulations provided by customize-cra are made for CRA 2.x.

An example, setting up two aliases:

• @ui points to <root>/src/ui
• @src points to <root>/src

1. Update tsconfig.json with your custom paths:

  "compilerOptions": {
    ...
    "baseUrl": "./src",
    "paths": {
      "@ui/*": ["ui/*"],
      "@src/*": ["./*"]
    },
    ...
  }

2. $ yarn add react-app-rewired customize-cra
3. Change all package.json scripts commands to use react-app-rewired instead of react-scripts.
4. Create a config-overrides.js file at the project root
5. Set up your paths overrides using the customize-cra helper addWebpackAlias

const path = require('path')
const { addWebpackAlias } = require('customize-cra')

module.exports = function override(config, env) {
  config = addWebpackAlias({
    ['@ui']: path.resolve(__dirname, 'src', 'ui'),
    ['@src']: path.resolve(__dirname, 'src')
  })(config)

  return config
}

6. At this point, your path aliases should be working.
7. To get the aliases working in Jest, add this to your package.json:

  "jest": {
    "moduleNameMapper": {
      "^@ui(.*)$": "<rootDir>/src/ui$1",
      "^@src(.*)$": "<rootDir>/src$1"
    }
  },

The react-app-rewired + customize-cra combo should allow you to change nearly anything you want in CRA without ejecting. I use it for path aliasing and Babel plugins where a macro is unavailable.

[jamsch]

Yeah, I currently have the following config which works fine on react-scripts-ts@3.1.0 however not here.

 "paths": {
      "~/*": [
        "src/*"
      ]
    },

[rolandjitsu]

@Timer while I understand the decision, I do hope that this is somewhere on the roadmap. Clearly, some of us (e.g. @lee-reinhardt) go to great lengths to figure out how to make this work.

I personally believe that it would be a valuable feature to have built in support for paths in CRA 2, and the effort to achieve this should be small, assuming it's just a matter of adding the webpack tsconfig-paths-webpack-plugin plugin.

@jamsch yes, react-scripts-ts does have support for paths. And they're also working on wmonk/create-react-app-typescript#409 to upgrade to CRA 2. But they're debating whether it's worth continuing given that CRA 2 also has support for TS.

The only difference, at the moment, between react-scripts and react-scripts-ts in terms of TS is path support and tslint (more or less). So adding path support here would eliminate the need of using react-scripts-ts which means that you do not need to wait for the maintainers of react-scripts-ts to upgrade CRA (they're usually doing a great job at being in sync with CRA) to get the newest features and that there are less chances for bugs to occur when the sync occurs.

Nonetheless, I'd be more than happy to give this a shot if pointed in the right direction.

EDIT: If babel is in charge of transforming ts to js, perhaps module-resolver could be an option?

[ahadcove]

I agree with @rolandjitsu, this is a pretty big concern. Every Typescript app I have made exploited Paths as much as possible. One of the beauties of using TS. I currently have a few projects in react-scripts-ts that I was converting over this weekend until I kept running into issues with paths. That's what led me here.

I really hope this is built into CRA sooner rather than later.

[rassie]

FWIW, I've managed to add paths support via craco like this:

First, a craco plugin is needed:

const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin');

module.exports = {
    overrideWebpackConfig: ({ webpackConfig, cracoConfig, pluginOptions, context: { env, paths } }) => {
        webpackConfig.resolve.plugins.push(new TsconfigPathsPlugin({}))
        return webpackConfig;
    }
};

Then, it needs to be added to craco configuration:

const logWebpackConfigPlugin = require("./craco-plugin");

module.exports = {
    plugins: [
        { plugin: logWebpackConfigPlugin }
    ]
}

Hope this will help someone on this thread. However, now I have to wonder whether it's all broken now due to #5609.

[rassie]

@Timer please consider changing value to suggested in #5609 to allow temporary hacks and workaround like the one I cited to continue to work. Thank you for understanding.

[jamsch]

Honestly I see paths as quite a necessity for any medium-large project because what inevitably happens is importing from the project root for components that are multiple levels deep which ends up like:

// src/components/ui/Button/Square.tsx
import colors from '../../../../res/colors.ts'; // instead of '~/res/colors.ts'

// src/pages/auth/signin/SignIn.tsx
import * as Button from '../../../../components/ui/Button';  // instead of '~/components/ui/Button'

Any further refactoring (such as moving components around) often end up messing the import path nesting unless IDE refactoring features save you.

This is a must-have for my use case so I'll probably end up ejecting if this isn't on the cards for the CRA team.

[Timer]

Closing as a duplicate of #5118.

TypeScript support will ship without support for baseUrl and paths.
Sorry for any inconvenience! I know it'll be a bit painful to switch back to relative paths.

Edit: we do want to support this in the future, it just didn't make it into the initial release. See this comment: #5585 (comment).