-
Notifications
You must be signed in to change notification settings - Fork 29.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support custom root directory alias for imports #14907
Comments
@waderyan IMO tsserver 2.0.3 is able to do this. They now support a rootPath. But you need to test. |
@jamietre thank you for opening this issue. This fell through the cracks for me so apologize it took some time. We have done a fair amount of work here. Can you try again with VS Code Insiders? If it is still not working can you share a workspace with me to test out the issue. |
@waderyan no problem - but how do I test it? I assume there needs to be some config to tell it what aliases e.g. ~ mean. |
@jamietre apologize that my writing was unclear. Please test the situation you described in this issue. Do we still "[lose] IntelliSense" when import paths are rewritten? If you have a workspace that shows the issue can you share it with me. |
I can create a workspace but it's quite simple really, module 1:
where the true relative path might be I think you might be unclear on the situation I am describing (or feature I am requesting) because import paths aren't being rewritten by VS Code, they are being rewritten during my build process by a babel plugin. VS Code would have no knowledge of this process or what the mappings meant, unless it actually did some analysis of the compiled code, or had specific knowledge of the plugin I mentioned and parsed The simple solution would be for some configuration in VS Code where I can tell it that for this workspace, |
@jamietre thank you for your explanation. I looked around in Atom and WebStorm but couldn't find how to do this. Can you point it out for me? We may want to adopt something similar. @mhegazy @bowdenk7 have either of you seen a request like this before? Is this something that could be done? Exploring the possible solutions right now. |
WebStorm has a feature called "resource root" which lets you use path aliases: This would be a very handy feature for developers using webpack. |
@Majomb thanks - sorry i totally missed this question. I am not an Atom user but the 'babel-plugin-module-alias' website says "Atom: Uses atom-autocomplete-modules and enable the babel-plugin-module-resolver option." An implementation of this feature that's compatible with e.g.
This would result in an import in file
being mapped to
as far as VS code is concerned. It would then be able to find the file and intellisense and everything else would work. This is exactly what the babel plugin does when you compile. Obviously the benefit of using this |
This is already supported using {
"compilerOptions": {
"baseUrl": "./", // all paths are relative to the baseUrl
"paths": {
"~/*" : ["*"] // resolve any `~/foo/bar` to `<baseUrl>/foo/bar`
}
}
} hope that helps. |
@mhegazy thanks for quick response. Seems that those compiler options are only allowed in tsconfig.json files and are missing from jsconfig.json. https://www.typescriptlang.org/docs/handbook/compiler-options.html (paths is marked with [2]) |
The option is honored in the two files. the schema needs to be updated in https://github.com/SchemaStore/schemastore/blob/master/src/schemas/json/jsconfig.json. PRs are welcomed. |
That looks exactly like what I'd expect! I am using insider, though can't think why that would make a difference for this. Will try in the release just to be sure.. The project I've been playing with is pretty huge, I'll try it in something more trivial to determine if it's my project or the environment. |
Also the ability to specify additional {
...
resolve: {
modules: [path.join(__dirname, 'js'), 'node_modules'],
...
},
...
} This allows for the ability to reference source files without direct path resolutions such as // from js dir
import api from 'data/api';
// from node modules
import _ from 'lodash'; |
I'm attempting to get this working (in a similar setup as @weikinhuang) without any luck. Should this work already? // jsconfig.json
{
"compilerOptions": {
"target": "ES6",
"module": "commonjs",
"allowSyntheticDefaultImports": true,
"baseUrl": "./",
"paths": {
"components/": ["src/components/*"],
"utils/": ["src/utils/*"],
"redux/": ["src/redux/*"],
"routes/": ["src/routes/*"],
"api/": ["src/api/*"]
}
}
} // Relevant webpack config:
const config = {
resolve: {
modulesDirectories: [
'src',
'node_modules',
],
extensions: ['', '.json', '.js', '.jsx'],
},
} // src/components/SomeComponent.js
import AnotherComponent from 'components/AnotherComponent'; // doesn't work
import TestComponent from './TestComponent' // works as expected |
You are missing an // jsconfig.json
{
"compilerOptions": {
"target": "ES6",
"module": "commonjs",
"allowSyntheticDefaultImports": true,
"baseUrl": "./",
"paths": {
"components/*": ["src/components/*"],
"utils/*": ["src/utils/*"],
"redux/*": ["src/redux/*"],
"routes/*": ["src/routes/*"],
"api/*": ["src/api/*"]
}
}
} From these mappings, it seems that all you need is to set the all path mapping entries are relative to you can read more about how path mapping works at: www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping |
@mhegazy, thank you so much, |
thanks 🌷. glad it worked. |
Closing as it sounds like this issue has been fixed. |
I'm actually still seeing issues with red squigglies and no go-to-definition for mapped paths. I'll try to get a minimum-reproducible repo up, but for now the two things that we're doing that might be unexpected are:
|
I am using Angular CLI my workaround solution: /tsconfig.json
/src/tsconfig.app.json
note: restart vs code is need |
As @marianban pointed out, this feature is not documented. I've raised a PR to fix this at microsoft/vscode-docs#942. |
This is still causing me issues. I've run through the various suggestions in this list, but can't figure out why it isn't working. VSCode: 1.12.2 jsconfig.json
|
set |
Thank you! That got rid of the red squiggly and error, but I'm still not getting intellisense. UPDATE |
can you share a repro project? |
Hi,
When I try and cmd click on say removeProps
I'm not able to jump to that function. |
can you share a repro project? |
I can try, I don't want share our prod code, but in short your saying it should work?
/stephen
…Sent from my iPhone
On 7 juni 2017, at 16:59, Mohamed Hegazy ***@***.***> wrote:
can you share a repro project?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Hmm, I'll fiddle again, although one thing is that I get an unknown configuration property in jasconfig for compilerOptions (squiggly line).. which you don't? Wondering if an extension is mucking things up?
…Sent from my iPhone
On 7 juni 2017, at 18:43, Mohamed Hegazy ***@***.***> wrote:
yup.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@maitriyogin found anything? Seems I'm on the same boat as you. Module resolution as been working on and off for me, for the past year or so. |
FYI, to get webpack 3 to compile relative modules that are declared in tsconfig/jsconfig.json 'paths' property, you have to also add them to webpack config's 'resolve.modules' property, ie: tsconfig.json:
webpack.config.js:
Hope it helps someone! |
@mhegazy setting moduleResolution works for me, but now I have the warning:
You have that warning on demo screenshot too. Is there any way to avoid the warning message? |
Try to add the 'modules' property within resolve, ie:
resolve: {
extensions: ['.js', '.jsx', '.ts', '.tsx'],
modules: [ 'node_modules' ] // try to add '@src', 'src', 'src/vue', etc...
},
…On Wed, Aug 9, 2017 at 4:42 PM, amritk ***@***.***> wrote:
Having issues with this as well, it compiles fine in webpack, but I get
the annoying red underline in vscode.
[image: screenshot from 2017-08-09 13-40-00]
<https://user-images.githubusercontent.com/2039539/29142921-47a6bf98-7d08-11e7-8cc8-a80bec6e1319.png>
tsconfig.json
{
"compileOnSave": false,
"compilerOptions": {
"allowSyntheticDefaultImports": true,
"lib": [
"dom",
"es2015",
"es2016",
"es6",
"es2017"
],
"target": "es2017",
"module": "es6",
"moduleResolution": "node",
"noImplicitAny": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"removeComments": false,
"baseUrl": ".",
"paths": {
***@***.***": ["."],
***@***.***": ["src/vue/community"],
***@***.***": ["src/vue/components"],
***@***.***": ["src"],
***@***.***": ["src/vue"]
},
"preserveConstEnums": true,
"sourceMap": true,
"skipLibCheck": true
}
}
webpack.base.conf.js
resolve: {
extensions: ['.ts', '.js', '.vue', '.json'],
alias: {
***@***.***': resolve('.'),
***@***.***': resolve('src/vue/community'),
***@***.***': resolve('src/vue/components'),
***@***.***': resolve('src'),
***@***.***': resolve('src/vue')
}
},
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#14907 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAWtmImaP2e832rU-wjVN3eGa2UfoPNcks5sWhmygaJpZM4KoVsB>
.
|
@rw3iss would the webpack config affect vscode? I thought vscode was resolving the paths from tsconfig.json My webpack is working properly, its just vscode that can't seem to find the modules |
Yeah, true. I don't know, I have the relative paths working within VSCode
on one of my projects. Here's the configs, if it helps:
(from within ./app/lib/Authentication.ts):
import User from 'models/User';
Here is my tsconfig.json:
{
"compilerOptions": {
"outDir": "./build/", // path to output directory
"sourceMap": true, // allow sourcemap support
"strictNullChecks": true, // enable strict null checks as a best practice
"module": "es6", // specifiy module code generation
"moduleResolution": "node",
"jsx": "react", // use typescript to transpile jsx to js
"target": "es2015", // specify ECMAScript target version
"allowJs": true, // allow a partial TypeScript and JavaScript codebase
"baseUrl": "./app",
"paths": {
"~/*": ["./*"],
"components/*": ["components/*"],
"lib/*": ["lib/*"],
"models/*": ["models/*"]
}
},
"include": [
"./app/**/*"
],
"exclude": [
"./node_modules/**/*"
],
"types": ["webpack-env"]
}
And my webpack config:
var webpack = require('webpack');
var path = require('path');
var BUILD_DIR = path.resolve(__dirname, 'build');
var APP_DIR = path.resolve(__dirname, 'app');
var config = {
entry: {
app: [
'webpack-dev-server/client?http://localhost:3000',
'webpack/hot/dev-server',
//'react-hot-loader/patch',
APP_DIR + '/entry.tsx'
]
},
output: {
publicPath: '/',
path: BUILD_DIR,
filename: '[name].js'
},
resolve: {
extensions: ['.js', '.jsx', '.ts', '.tsx'],
alias: {
components: path.resolve(__dirname, "app/components"),
lib: path.resolve(__dirname, "app/lib"),
models: path.resolve(__dirname, "app/models"),
},
modules: [ 'node_modules', 'app', 'app/models', 'app/components', 'app/lib'
]
},
module: {
loaders: [
{
test: /\.(t|j)sx?$/,
include: APP_DIR,
exclude: /node_modules/,
loader: ['ts-loader']
}
]
},
plugins: [
new webpack.HotModuleReplacementPlugin(),
new webpack.NamedModulesPlugin()
],
devServer: {
hot: true,
contentBase: './',
publicPath: '/',
public: 'http://localhost:3000',
port: 3000
}
};
module.exports = config;
…On Wed, Aug 9, 2017 at 4:47 PM, amritk ***@***.***> wrote:
@rw3iss <https://github.com/rw3iss> would the webpack config affect
vscode? I thought vscode was resolving the paths from tsconfig.json
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14907 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAWtmD1s0QjId7yu4HOCwGn3jyRfcYv5ks5sWhrdgaJpZM4KoVsB>
.
|
@rw3iss hey thanks for your help! turns out VSCode doesn't like them starting with an '@' symbol. |
Sweet, yeah I was curious about that, seemed like it might not. Glad you
got it figured out!
…On Wed, Aug 9, 2017 at 5:12 PM, amritk ***@***.***> wrote:
@rw3iss <https://github.com/rw3iss> hey thanks for your help! turns out
VSCode doesn't like them starting with an '@' symbol.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14907 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAWtmLFiCwypYwpozNCx1K74fsADSRqnks5sWiCpgaJpZM4KoVsB>
.
|
I'm using Inseider. Intellisense did not work in the React project. jsconfig.json OK {
"compilerOptions": {
"jsx": "react",
"baseUrl": ".",
"paths": {
"~/*": ["./*"]
}
}
} jsconfig.json NG
|
it's not ok in html,there is a snippets:
but in fact the file is in |
Can't get this to work, please help. Intellisense is still not working. Inside index.ts I already get folder completion ('src/components'), but no .vue file completion : Inside 'Hello.vue', there's no Intellisense whatsoever : tsconfig.json : "compilerOptions": { |
jsconfig.json for vue-cli webpack template: {
"compilerOptions": {
"baseUrl": "./",
"paths": {
"@/*": ["src/*"],
}
}
} jsconfig.json located in the root of project |
If you are running into problems related to import paths, please try asking on stackoverflow or posting a new issue |
VSCode depends on being able to resolve
import
ed references for intellisense. So when using something that rewrites import paths -- specifically: babel-plugin-module-resolver -- we lose intellisense.This is very useful for large projects, because it avoids deeply nested path resolutions, e.g.
import 'thing-to-test' from '../../../../../src/feature/subfeature/helper/thing
These are a big nuisance because apart from being ugly & it's hard to locate the file in the first place, anytime you move a code block, you have to refactor them. The aforementioned module lets you define an alias like "~=/src" and then just:
import 'thing-to-test' from '~/feature/subfeature/helper/thing
Atom and Webstorm are both capable of being configured with information about such aliases to enable them to resolve the paths correctly.
Is there any way this capability can be added to VS Code? I really want to be able to continue to use these, but the loss of intellisense is tough to swallow.
The text was updated successfully, but these errors were encountered: