Support for monorepos or other non-typical folder structures

[arggh]

Currently it seems that this package tries to search for packages in ./packages folder.

Would be great, if that was configurable. Some projects consist of multiple Meteor apps that share common local Meteor packages. The folder structure could look like this:

- npm-packages /
    - custom-npm-module1
- meteor-packages /
    - custom-package1
    - custom-package2
- app1
- app2
- app3

[mattblackdev]

@arggh Nice! How do you feel about a vs code setting for this?

[arggh]

A setting would definitely work. I was also thinking, could the METEOR_PACKAGE_DIRS env variable be exploited, if found? I have all my local folders containing Meteor packages listed in there.

[mattblackdev]

@arggh I could use a little advice on that. Would METEOR_PACKAGE_DIRS be available in the vs code extension execution context? Or would it have to be something fancy like finding it in a package.json npm script or meteor settings file etc..?

[arggh]

I've never studied VS Code extensions, but normally in Node you access env vars via process.env.METEOR_PACKAGE_DIRS.

[arggh]

I'm not sure if this is proof regarding extensions, but at least you can access environment variables in the dev tools of VS Code:

[arggh]

I gave this a quick try, and without knowing much of how extensions work, I could only get access to folders inside current workspace through VS Code's APIs (which seems reasonable).

But you sure can access process.env.METEOR_PACKAGE_DIRS.

[mattblackdev]

@arggh nice work! So around line 28 in extension.js there is the hard-coded search in packages/. But this is a vs code workspace search.

      // Find all the local package.js files inside /packages folder
      vscode.workspace
/* 28 */.findFiles('packages/**/package.js')
        .then(packageFileURIs => {
          Promise.all(
/* 31 */    packageFileURIs.map(uri => {
              return new Promise((resolve, reject) => {
                fs.readFile(uri.fsPath, 'utf-8', (err, data) => {
                  if (err) {
                    reject(err)
                  } else {
                    const packagePath = vscode.workspace.asRelativePath(
                      path.parse(uri.fsPath).dir
                    )
                    const code = data.toString()
                    resolve({ code, packagePath })
                  }
                })
              })
            })
          )

I think to support our case it needs to be modified to do multiple normal file system searches.

• One or more for METEOR_PACKAGE_DIRS (I think it can have multiple paths)
• Another or more for the vs code setting we're proposing (this could support multiple paths as well)
• and finally the original local packages folder.

Then we could join all the results and continue with the Promise.all(packageFileUris.map(//...)) on line 31.

I'm also wondering if any of these ways to specify paths should override any of the others? What do you think?

[arggh]

You're correct, METEOR_PACKAGE_DIRS can have multiple paths. I thought I'd share my PoC -branch as a starting point. It currently uses the original local packages folder and METEOR_PACKAGE_DIRS (splitting the path and including all of them).

About overriding: Do you mean, if we have the same package in two different locations, which one do we use?

I guess we could rely on Meteor's loading pattern, where the local package in ./packages always comes first.

About METEOR_PACKAGE_DIRS versus a folder in the extension's configs... I'm not so sure. Maybe prefer the directory in extension's configuration as a priority, if the default config is empty.

Then, the developer knows he/she has declared an overriding configuration setting in VS Code. Does that sound reasonable?

[arggh]

It's been a while, but I also noticed (trying to use this extension again) that it doesn't pick up symbolic links.