To simplify your development workflow, consider using both the baseUrl and paths configuration.

If your project's root directory is located within the main src folder (assuming I understood correctly), update your TypeScript configuration file as follows:

// tsconfig.json
{
  "compilerOptions": {
    ...
    "baseUrl": ".",
    "paths": {
      "lib/*": [
        "src/org/global/lib/*"
      ]
    }
  }
}

To ensure proper module resolution with Webpack, you may also need to include a resolve configuration. For Webpack 2 compatibility, you can add the following lines in your webpack configuration file:

// webpack.config.js
module.exports = {
    resolve: {
        ...
        modules: [
            ...
            './src/org/global'
        ]
    }
}

Explore these related solutions featuring asterisks

  "baseLocation": ".",
  "routes": {
    "*": [
      "modules/*",
      "source/types/*"
    ]
  },

If you want a simple way to reference your root folder using @, follow this minimalist example:

{
  "compilerOptions": {
    "baseUrl": "src",
    "paths": {
      "@/*": ["*"]
    }
  }
}
// Usage example: import * as logUtils from '@/utils/logUtils';

Alternatively, if you prefer to include the src folder in your imports, you can do so with this configuration:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["*"]
    }
  }
}
// Usage example: import * as logUtils from '@/src/utils/logUtils';

I found a solution that works well for me:

npm install --save-dev tsconfig-paths

ts-node -r tsconfig-paths/register <your-index-file>.ts

By using this method, all paths in the tsconfig.json file are loaded. Here is an example of a tsconfig.json file:

{
    "compilerOptions": {
        {…}
        "baseUrl": "./src",
        "paths": {
            "assets/*": [ "assets/*" ],
            "styles/*": [ "styles/*" ]
        }
    },
}

It is important to have both baseUrl and paths configured for this method to work properly.

With this setup, you can then import modules like this:

import {AlarmIcon} from 'assets/icons'

When transitioning from TypeScript to JavaScript, it's important to convert absolute paths back to relative paths for proper functionality. One commonly used tool for this task is tsc.

Although many opt for using tsconfig-paths, I found that it didn't suit my needs due to its runtime path resolution which could impact package size and performance.

To address this, I created my own solution called tscpaths. This tool replaces paths during compilation, eliminating any runtime dependencies or performance issues. Integration is simple by adding a line to your build scripts in the package.json file.

While tscpaths has worked seamlessly for my somewhat complex setup, as with any new project, there may be some challenges with highly intricate configurations. It’s a promising tool that offers efficiency without sacrificing simplicity.

For those utilizing tsconfig-paths without success, consider adjusting the tsconfig.json file:

{
  // ...
  "compilerOptions": {
    "outDir": "dist",
    "rootDir": "src",
    "baseUrl": ".",
    "paths": {
      "@some-folder/*": ["./src/app/some-folder/*", "./dist/app/some-folder/*"],
      // ...
    }
  },
  // ...
}

If @some-folder/some-class is not found by the compiler, it will search in either ./src... or ./dist....

Alejandro's solution was the key for me. However, since I am utilizing the awesome-typescript-loader in conjunction with Webpack 4, I found it necessary to incorporate the tsconfig-paths-webpack-plugin into my webpack.config file to ensure proper resolution of paths.

It’s a matter of perspective. Rather than using the code snippet below

import { Something } from "../../../../../lib/src/[browser/server/universal]/...";

We can eliminate the need for the "../../../../../". It seems out of place and is not very clear.

The solution lies in the TypeScript configuration file. Simply set the baseUrl property, and the configuration will handle your relative paths seamlessly.

How to configure: Within the tsconfig.json file, include the following properties.

"baseUrl": "src",
    "paths": {
      "@app/*": [ "app/*" ],
      "@env/*": [ "environments/*" ]
    }

Therefore, ultimately it will appear as follows:

import { Something } from "@app/src/[browser/server/universal]/...";

This results in a more straightforward, impressive, and easily readable format...

To Utilize:

{
  "compilerOptions": {
    "baseUrl": "src"
  },
  "include": ["src"]
}

Uncertain if specifying paths is necessary. However, after setting baseUrl to src, I am able to import all directories within the src directory using this method:

import {Home} from "pages";
import {formatDate} from "utils";
import {Navbar} from "components";

Remember to restart your terminal after modifying the tsconfig.json.

For those utilizing TypeScript with Webpack 2 and at-loader, there is an extra step to consider (mleko's solution didn't fully solve the issue for me):

// tsconfig.json
{
  "compilerOptions": {
    ...
    "rootDir": ".",
    "paths": {
      "lib/*": [
        "src/org/global/lib/*"
      ]
    }
  }
}

// webpack.config.js
const { TsConfigPathsPlugin } = require('awesome-typescript-loader');

resolve: {
    plugins: [
        new TsConfigPathsPlugin(/* { tsconfig, compiler } */)
    ]
}

Enhanced path resolution in TypeScript 2.0

If you're looking to simplify your imports in Node.js, one way is to utilize Subpath patterns.

Take for instance, updating your package.json with the following configuration...

{
    "imports": {
        "#lib": "./build/path/to/lib",
        "#lib/*": "./build/path/to/lib/*",
    }
}

This setup allows for cleaner import statements that steer clear of relative paths.

import { something } from "#lib"

Remember, these must begin with a hash and be correctly specified in your package.json linking to your build directory for Node.js to identify them.

In addition, consider including similar configurations in your tsconfig.json file if you're using TypeScript:

{
    "compilerOptions": {
        "baseUrl": ".",
        "paths": {
            "#lib": ["./src/path/to/lib"],
            "#lib/*": ["./src/path/to/lib/*"],
        },
    },
}

It seems like React has recently been updated, and as a result, you are no longer able to define the "paths" in the tsconfig.json file.

React now displays a helpful warning message:

Your tsconfig.json file will undergo the following changes: \

• compilerOptions.paths must not be set (aliased imports are not supported)

Subsequently, it automatically updates your tsconfig.json by removing the entire "paths" section. To work around this issue, you can execute the command

npm run eject

This action will expand all the configurations of create-react-scripts, incorporating config and scripts directories along with build/configuration files into your project. This also grants more flexibility in controlling how everything is structured, named, etc., through modifications in the {project}/config/* files.

Remember to update your tsconfig.json as follows:

{
    "compilerOptions": {
        "baseUrl": "./src",
        {…}
        "paths": {
            "assets/*": [ "assets/*" ],
            "styles/*": [ "styles/*" ]
        }
    },
}

Developing a component library

If you're in the process of creating a library that provides UI components (such as react-bootstrap or Ant Design), then these configurations should be beneficial for your project.

"compilerOptions": {
        ....
        "rootDir": "src",
        "baseUrl": ".",
        "paths": {
            "src/*": ["src/*"],
            "components/*": ["src/components/*"],
        }
  },

To better understand how the compiler works, take a look at this resource.

In my project file, I have included baseUrl as shown below:

"baseUrl": "src"

This setup is functioning correctly. Make sure to specify the base directory for your own project.

2021 Solution:

Note: CRA. At first, the concept of incorporating a third-party library or ejecting the app for aliasing seemed unconventional to me. However, after 8 hours of research (and experimenting with ejection), it became evident that this approach is the most efficient.

Step 1.

yarn add --dev react-app-rewired react-app-rewire-alias

Step 2. Create config-overrides.js file in the root directory of your project and populate it with the following:

const {alias} = require('react-app-rewire-alias')

module.exports = function override(config) {
  return alias({
    assets: './src/assets',
    '@components': './src/components',
  })(config)
}

Step 3. Modify your package.json file:

  "scripts": {
-   "start": "react-scripts start",
+   "start": "react-app-rewired start",
-   "build": "react-scripts build",
+   "build": "react-app-rewired build",
-   "test": "react-scripts test",
+   "test": "react-app-rewired test",
    "eject": "react-scripts eject"
}

If @declarations are not functioning, include them in the d.ts file. For instance: '@constants': './src/constants', => add in react-app-env.d.ts declare module '@constants';

That's all. You can now proceed using yarn or npm start/build/test commands as usual.

Complete version available in the documentation.

Note: The Using with TypeScript / JavaScript configuration section in the docs did not yield results for me. The error "aliased imports are not supported" persisted during the project build. Hence, I opted for a simpler method. Fortunately, it worked effectively.

/ originates from the base directory. For a relative path, it is necessary to utilize ./ or ../.

It is crucial that the <code>baseUrl

import Product from '@app/components/Product';

src/components/Product.tsx

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

Ensure that you possess the following:

{
    "compileOnSave": true,
    "compilerOptions": {
        "paths": {
            "@styles/*": ["assets/scss/*"]
        }
    },
}

This was causing some trouble for me.

In my experience, Visual Studio Code was having trouble recognizing the path, even though the project was still able to build successfully. The issue turned out to be that I had the paths declaration in a separate tsconfig.app.json file.

After moving the paths property from tsconfig.app.json into the main tsconfig.json, the problem was resolved.

It seems that this is because Visual Studio Code only checks the first tsconfig.json file it encounters in the project's root directory. However, I have not personally verified this. If anyone has more information on this, please feel free to leave a comment.