VSCode & Absolute Imports


#1

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.


#2

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.


#3

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.


#4

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.


#5

Hmm. Adding Flow type checking isn’t a bad idea for me, but adding it just to fix this path importing isn’t ideal.


#6

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.


#7

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…


#8

FWIW disabling unused global symbol inspection helps a lot but yeah I agree they’re gouging on it


#9

I’m not using Typescript.


#10

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


#11

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.


#12

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"
  }

#13

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..."
]

#14

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.


#15

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