Support absolute imports with @

[xiaoxiangmoe]

webpack.base.conf.js wrote as below:

resolve: {
    extensions: ['.js', '.vue', '.json'],
    alias: {
      '@': resolve('src'),
    }
 },

https://github.com/vuejs-templates/webpack/blob/master/template/build/webpack.base.conf.js#L40

Can we use import Hello from '@/components/Hello' like vue?

[Timer]

Place NODE_PATH=src into your .env file and proceed to import components/Hello.

[gaearon]

I’d say let’s just add @ support. I was resistant because I thought we’d do monorepos sooner. But since that was shelved we might as well do what Vue does.

[Timer]

We'll need to make sure it works with webpack (obviously), but also Jest/Flow/ESLint(?).

[gaearon]

Can we just create node_modules/@ and link it?

[xiaoxiangmoe]

@gaearon Why does monorepos affect @ support?

[gaearon]

If we had monorepo support we’d encourage people to put different top level folders into separate packages instead of having a special way to refer to the root.

[xiaoxiangmoe]

By the way, our individual packages in monorepo, if we don't want to publish it to NPM, how should it be named?

[gaearon]

Doesn't matter.

[xiaoxiangmoe]

@gaearon

If we had monorepo support we’d encourage people to put different top level folders into separate packages instead of having a special way to refer to the root.

I think even with monorepo, we still need a special way to refer to the root.

For example, if we needs two axios instances, it would be unreasonable for us to put these strongly business-relevant codes in separate packages.

[iremlopsum]

@gaearon any update on this?

[tanduong]

The simplest way to achieve this is to create node_modules/@ and link it as @gaearon suggested. You could do this by adding a postinstall script to your package.json. Like this:

{
  // ...
  "scripts": {
    "preinstall": "rm node_modules/@",
    "postinstall": "ln -s `pwd`/src node_modules/@",
    // ...
  },
  // ...
}

[robertvansteen]

If we would proceed with this would NODE_PATH support be dropped? Because I’d prefer that over any prefix symbol. I also think for people new to JS/React an absolute path like components/button feels natural while something like @/components/button is yet another thing they need to learn and needs to be explained.

[tanduong]

@rovansteen I personally prefer an explicit symbol so that I can tell whether the imports come from the application code or a node module. If @ looks weird, you may try with: src, @src, app, @app, ... instead.

[robertvansteen]

@tanduong it's not about that the @ looks weird it's about that it is not a common pattern for paths. Relative paths starting with a . and absolute paths not starting with a dot is a much more common pattern.

[robertvansteen]

You could then argue if the absolute path should be the root directory of the application or the src directory. If you'd go with the root directory you do have the benefit of having to "prefix" all of your absolute imports of your application code with src. I don't know if there's any upside/downside of NODE_PATH vs. webpack alias if you go with src as the prefix.

[dmythro]

Is there any IDE support on this for proper auto-complete etc?

Didn't see such practice on corporate projects before. But relative paths are very annoying indeed.

[yordis]

@Z-AX definitely IDEs auto-complete and indexing will become an issue.

Even in Vue, I didn't use this.

It sounds good, it looks good, but in practice becomes an issue.

[xiaoxiangmoe]

@Z-AX
For js file，we can write a fake webpack config, see umijs/umi#1109
For ts file, we can use paths in tsconfig, see #5645

[fooey]

Is there any IDE support on this for proper auto-complete etc?

Didn't see such practice on corporate projects before. But relative paths are very annoying indeed.

VS Code at least supports jsconfig.json which uses the exact same "paths" options as tsconfig to tell the editor how to resolve paths.

https://code.visualstudio.com/docs/languages/jsconfig

So far as I can tell, TypeScript does not support NODE_PATH. I was adopting TypeScript in an existing CRA app relying on NODE_PATH, and tsconfig's path options saved me from running into a big blocker while CRA's typescript support was in beta.

@tanduong's proposal for a filesystem link isn't OS independent, so now I'm stalled trying to figure out what to do with a project I over optimistically started porting over to typescript and is just completely broken ATM

edit: Using a collage of packages (rimraf, lnk-cli, globstar), I think I have a cross environment happy pre/post install setup that seems to be mostly working

scripts: {
		"preinstall": "yarn unlink-modules",
		"postinstall": "yarn link-modules",
		"unlink-modules": "rimraf node_modules/@",
		"link-modules": "globstar --node -- lnk \"./src/*\" \"./node_modules/@/\"",
		"relink-modules": "yarn unlink-modules && yarn link-modules",
		// ...
}

[gaearon]

There appears to be some confusion in other threads so I'll repeat my comment from #5585:

---

Just to be clear — we do want to support absolute paths.

In particular, we want to:

• Make NODE_PATH work for TS. (Fix baseUrl for NODE_PATH=src #5692)
• Make @ alias work by default for everyone — both in JS and TS. (this issue)

I'm sorry for the frustration this is causing. We're not asking you to convert your code to use relative paths — but please wait for either of these two issues to resolve.

[gaearon]

There is also another plausible alternative — we could embrace tsconfig.json / jsconfig.json, and make paths specified there work across the setup (Webpack/Jest). See #5645 (comment) for that.

[jakewies]

tsconfig.json/jsconfig.json specify a baseUrl too. This is one of the items on the list of things to do along with this issue. If CRA embraces the paths option, can it embrace the baseUrl as well?

[gaearon]

Probably — let's discuss in #5645? I don't fully understand what this entails.

[Kepro]

what about... '@/': paths.appSrc + '/',
I'm using this for long time and without any issues... :)

[mzvast]

The simplest way to achieve this is to create node_modules/@ and link it as @gaearon suggested. You could do this by adding a postinstall script to your package.json. Like this:

{
  // ...
  "scripts": {
    "preinstall": "rm node_modules/@",
    "postinstall": "ln -s `pwd`/src node_modules/@",
    // ...
  },
  // ...
}

This script is so DANGEROUS!
It DELETE all my src folder!

[jjvainstein]

Messing around I just found one setting that works without craco for the absolute paths:

1 - Update .env file to NODE_PATH=./;

2 - Create one tsconfig.paths.json:

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

3 - Add this as your first entry in tsconfig.json:

"extends": "./tsconfig.paths.json",

Now everything should work fine, just reference the src/ folder in your imports instead of @.

YES, CRA will complain about the tsconfig.json absolute paths and stuff, but... VSCode seems to work pretty well with it and I think other IDEs will just as well.

EDIT: CRA complains but don't really remove the lines because it extends from the paths.json file so it can't modify it!

Hi! I tried this solution but is not working for me. This is my tsconfig.json:

{
"extends": "./tsconfig.paths.json",
"compilerOptions": {
"target": "es5",
"lib": [
"dom",
"dom.iterable",
"esnext"
],
"allowJs": true,
"skipLibCheck": true,
"esModuleInterop": true,
"allowSyntheticDefaultImports": true,
"strict": true,
"forceConsistentCasingInFileNames": true,
"module": "esnext",
"moduleResolution": "node",
"isolatedModules": true,
"noEmit": true,
"jsx": "preserve",
"noUnusedLocals": true,
"noUnusedParameters": true,
"resolveJsonModule": true
},
"include": [
"src"
]
}

[jjenzz]

My solution:

yarn add react-app-rewired --dev

Update package.json scripts:

"scripts": {
  "start": "react-app-rewired start",
  "build": "react-app-rewired build",
  "test": "react-app-rewired test --env=jsdom",
  "eject": "react-app-rewired eject"
},

Add config-overrides.js to project root:

const path = require('path');

module.exports = function override(config) {
  config.resolve = {
    ...config.resolve,
    alias: { '@': path.resolve(__dirname, 'src') },
  };

  return config;
};

Add jsconfig.paths.json/tsconfig.paths.json to project root:

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

Add the following to jsconfig.json / tsconfig.json:

"extends": "./tsconfig.paths.json", // or jsconfig.paths.json

CRA warns about compilerOptions.baseUrl and compilerOptions.paths not being supported but everything works as expected.

[Ruffeng]

@jjenzz your solution works smooth!

Hope the core team will provide a solution without other packages to achieve it ...

[jjvainstein]

My solution:

yarn add react-app-rewired --dev

Update package.json scripts:

"scripts": {
  "start": "react-app-rewired start",
  "build": "react-app-rewired build",
  "test": "react-app-rewired test --env=jsdom",
  "eject": "react-app-rewired eject"
},

Add config-overrides.js to project root:

const path = require('path');

module.exports = function override(config) {
  config.resolve = {
    ...config.resolve,
    alias: { '@': path.resolve(__dirname, 'src') },
  };

  return config;
};

Add jsconfig.paths.json/tsconfig.paths.json to project root:

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

Add the following to jsconfig.json / tsconfig.json:

"extends": "./tsconfig.paths.json", // or jsconfig.paths.json

CRA warns about compilerOptions.baseUrl and compilerOptions.paths not being supported but everything works as expected.

Thanks for your solution. One silly question, how I can use to solution to avoid using '@'? I mean, instead of doing `@/components/DummyComponent' I would like to do 'components/DummyComponent'.

[Kepro]

@jjvainstein rly? :) second comment in this thread

[jjvainstein]

@jjvainstein rly? :) second comment in this thread

@Kepro that simple solution doesn't work for me and many other people. I tried creating that .env file with it doesn't work. So for that reason I was thinking that with the solution using eact-app-rewired plus some modification I can achieve that.

[aramvr]

There appears to be some confusion in other threads so I'll repeat my comment from #5585:

Just to be clear — we do want to support absolute paths.

In particular, we want to:

• Make NODE_PATH work for TS. (Fix baseUrl for NODE_PATH=src #5692)
• Make @ alias work by default for everyone — both in JS and TS. (this issue)

I'm sorry for the frustration this is causing. We're not asking you to convert your code to use relative paths — but please wait for either of these two issues to resolve.

Is there any news?

[robertvansteen]

@aramvr there is a work-in-progress PR (#6116) and I believe the intention is to ship it with 3.0 but there is still some work to do.

[mchurichi]

just wanted to add to @jjenzz solution that you also need to map @ to the right path if you want jest to resolve correctly... this worked for me

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

[rambabusaravanan]

Messing around I just found one setting that works without craco for the absolute paths:

1 - Update .env file to NODE_PATH=./;

2 - Create one tsconfig.paths.json:

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

3 - Add this as your first entry in tsconfig.json:

"extends": "./tsconfig.paths.json",

Now everything should work fine, just reference the src/ folder in your imports instead of @.

YES, CRA will complain about the tsconfig.json absolute paths and stuff, but... VSCode seems to work pretty well with it and I think other IDEs will just as well.

EDIT: CRA complains but don't really remove the lines because it extends from the paths.json file so it can't modify it!

This really works super awesome ..
Thanks @zaguiini ..

[ianschmitz]

baseUrl is now supported in tsconfig.json and jsconfig.json. Check out #6475 and install our alpha release if you want to try it out!

[nik-lampe]

This enables me to use absolute paths, but not aliases, right?

// edit
Nevermind, just read in #6656 that it's the case