VSCode intellisense is looking for absolute paths that don’t start with “/”, but Meteor is looking for the opposite.
Works with Meteor but not VSCode:
import { getProduct } from '/imports/api/products/methods';
Works with VSCode but not Meteor:
import { getProduct } from 'imports/api/products/methods';
How is everyone else dealing with this. Def driving me nuts having to work around this anytime I import anything.
Ran into this same issue as well.
I decided to wait until Babel 7 comes out with TypeScript support. In the meantime I’m using flowtype for type checking. It doesn’t suffer from the same issues though the IDE support is not as good, though not horrible.
I know this is not the best answer, but perhaps would you consider using Webstorm?
It has support for this, amazing debugging experience, very good coding assistance and increadible refactoring tools.
I’ve used Webstorm in the past extensively. It’s slow and expensive, so def not looking to go back. VSCode is really one of the most popular text editors, so it’s a pretty huge bummer that Meteor and VSCode can’t play nice on the absolute paths.
Hmm. Adding Flow type checking isn’t a bad idea for me, but adding it just to fix this path importing isn’t ideal.
For anyone interested in a solution, klaussner pointed out on Github that https://github.com/tleunen/babel-plugin-module-resolver will work. Adding
{
"plugins": [
["module-resolver", {
"root": ["./"]
}]
]
}
to my .bablerc file allows you to import via
import { getProduct } from 'imports/api/products/methods';
fixing intellisense.
How are you combining babel and TypeScript ? I was wanting to do something similar but thought I’d need to wait until Babel 7 is supported by Meteor…
I’m not using Typescript.
I’ve found using the eslint plugin eslint-plugin-import and eslint-import-resolver-meteor to check paths means that it works with no problems
https://www.npmjs.com/package/eslint-import-resolver-meteor
Could you share how you configured it? For me with the default conf it just starts introducing “The keyword ‘import’ is reserved” for every import statement.
I have something like this in my package.json (versions may be different):
"devDependencies": {
"babel-eslint": "^7.1.1",
"eslint": "^2.13.1",
"eslint-config-airbnb": "^9.0.1",
"eslint-import-resolver-meteor": "^0.2.4",
"eslint-plugin-import": "^1.9.2",
"eslint-plugin-jsx-a11y": "^1.5.3",
"eslint-plugin-meteor": "^3.6.0",
"eslint-plugin-react": "^5.2.2"
}
Here’s the part of my eslint config that’s relevant
.eslintrc.js:
plugins: ['meteor', 'import', 'etc...'],
extends: [
'plugin:meteor/recommended',
'plugin:import/errors',
'plugin:import/warnings',
'etc...',
],
settings: {
'import/resolver': 'meteor',
},
and dependencies
package.json:
"devDependencies": [
"eslint-import-resolver-meteor": "^0.4.0",
"eslint-plugin-import": "^2.7.0",
"eslint-plugin-meteor": "^4.1.4",
"etc..."
]
I think there might be some confusion here. This isn’t an eslint issue. https://github.com/tleunen/babel-plugin-module-resolver and the config posted above fixes the problem.
As in their built in import suggestions?
I thought it was linting errors, ie. can’t resolve imported module. My mistake
In that case I’m using the import-js plugin for that: https://github.com/dabbott/vscode-import-js. It has built in meteor import resolution, including absolute, relative and package paths. It still has some issues resolving the correct path for local packages, but it’s close.
I started using it on Sublime and kept it when I moved to VSCode. I’ve kept using it over the built in imports resolution because of it’s meteor support
The issue has been resolved, there is no need for babel plugin now. Assuming basic project structure, jsconfig.json file must contain the following lines to make path intellisense work:
{
"compilerOptions": {
"baseUrl": ".",
"paths": {
"/*": ["./*"]
}
}
}
Worked for me. One note, once file added you need to restart VS Code to apply changes.
