@coagmano WOW! Those comments are a gold mine!! Check this out. Looks like I was right about the ~/.meteor dir, but apparently I never looked inside it . The packages are all in there plain as day… But in this case getting the mainModule is not as simple.
The first step will be to deduce the package version to get the file path to the package code. I think that can be obtained from the project’s
.meteor/versions file. Once it has that it will need to get the mapping between the package name and the paths for VS Code.
There are package.js files, but they only have this:
// This file is included for compatibility with the Meteor 0.6.4 package downloader.
Another delicious comment:
// There are two ways that meteor packages expose their exported interface,
// pre-ES6 and post-ES6.
It looks like getting the paths for pre-ES6 packages is going to be difficult. AFAIK, there’s no mapping:
// The pre-ES6 modules method is to call api.exports within the package.js
// file for each variable exported. These calls all result in declaredExports
// entries in the individual platform's json files. Within
// aldeed:simple-schema's web.browser.json for example, we find
// "declaredExports": [
// "name": "SimpleSchema",
// "testOnly": false
// "name": "MongoObject",
// "testOnly": false
// "name": "humanize",
// "testOnly": true
// From this, we can determine that the namedExports entry should be
// 'aldeed:simple-schema': ['SimpleSchema', 'MongoObject']
My understanding is for
import-js that’s all they need, but for our case, we need to know what files to point VS Code to.
So, I’m stuck there. Likely that we’ll need a completely different approach.
For post-ES6 packages, I see a way.
web.browser.json (and probably the other architectures’ similar files) has this bit:
The extension can collect the mappings from this
resources field where objects have
fileOptions.mainModule = true.
I’m not gonna lie, tackling this seems like a lot of work and probably not the best use of time considering we’ve all made it this far without IntelliSense…but it also seems possible, at least for newer packages using ES6 modules. So, I think I’ll leave it up to the community to decide if it’s worth it, or propose a better way.
For now, I’m going to focus on local packages and supporting the
METEOR_PACKAGE_DIRS option since this is lower hanging fruit and will directly benefit VulcanJS and my needs at work.