Apollo-tooling: VSCode: Plugin doesn't work in multi-root workspaces

[deftomat]

I finally create a working apollo.config.json (which is really hard as docs are missing or incorrect).

Config looks like this:

module.exports = {
  client: {
    name: 'dev',
    service: {
      url: 'http://localhost:3130/graphql',
      localSchemaFile: 'packages/api/src/schema.graphql'
    },
    includes: ['packages/web/src/**/*.{ts,tsx,js,jsx,graphql}']
  }
};

Everything works as expected until you use multi-root workspaces feature.

In multi-root workspace, plugins throws the following error:

Unable to read file packages/api/src/schema.graphql. ENOENT: no such file or directory, open 'packages/api/src/schema.graphql'

[ianks]

Same here, essentially the apollo plugin is not reading relative to the actual apollo.config.js for me.

[arolson101]

I'm getting this, too.
I see in the output with trace bumped up that it seems to be getting the first element in the workspace and using that as the root, so the relative paths get screwed up. E.g.:

[Trace - 2:42:45 PM] Sending request 'initialize - (0)'.
Params: {
    "processId": 74836,
    "rootPath": "c:\\ag\\packages\\app",
    "rootUri": "file:///c%3A/ag/packages/app",
    "capabilities": {

I found that if I use paths relative to the 'app' folder then it works:

module.exports = {
  client: {
    service: {
      name: 'ag',
      localSchemaFile: 'dist/schema.json'
    },
    includes: ['**/*.tsx'],
  },
}

[JakeDawkins]

Is this issue still happening on the latest version of the extension? This has seen a lot of work recently and I assume it's been fixed. I'll close this issue if it's old :)

[elliottsj]

I'm still experiencing this issue, using version 1.5.2 of the VSCode extension.

[deftomat]

The same for me. It's still not working.

[Zik42]

same, any work around this issue?

[JakeDawkins]

I haven't had time to dig into this quite yet, but it's still on my radar

[intellix]

Getting this for Angular CLI NX generated projects where you have apps and libs in root. More info here: https://spectrum.chat/apollo/general/vsc-apollo-only-gives-intellisense-on-files-within-src-directory~0c45a389-9bfb-45ab-8810-81cbe683390f

[galvesribeiro]

Hey @JakeDawkins!

As we talked on Spectrum, yeah, I'm on latest version and on OSX and the service schema doesn't work either.

[JakeDawkins]

So apparently I was mistaking a "monorepo" as a multi-root workspace 🙈. We haven't built proper support for them quite yet into the extension

[aleccool213]

@JakeDawkins Plans to do this? Where would someone look to start working on this?

[timdeng2324]

any idea when this might be released?

[JakeDawkins]

@timdeng2324 Hi!

This is something that we definitely want to get supported, and I agree it'd be a great experience! As we released federation, there were some questions that got raised internally about how multi-root projects would interact with each other in a more dynamic way that also requires some config and project setup changes that we're not quite ready to rebuild.

tldr; we _will_ have this at some point, but it's not a feature with a set timeframe or schedule to work on it.

For the above reasons, I'd also advise anyone else against trying to implement this on your own. It's a spiderweb of dependency questions 😬😬

[iki]

@JakeDawkins do we really need anything complex?

My primary goal for fixing the relative localSchemaFile by resolving the path as relative to apollo.config.js reported in #1666 and https://github.com/apollographql/apollo-tooling/issues/669#issuecomment-484400735 was to avoid the popping extension errors in VS Code, when working in a multi-root workspace, where one of the project parts uses apollo CLI. This alone would be a progress and would allow people to use apollo CLI as documented without temporary workaround hacks like https://github.com/apollographql/apollo-tooling/issues/669#issuecomment-551451092. Importantly, resolving the import relatively is a correct way and it doesn't break anything.

Secondary goal would be to make the extension work exactly as apollo CLI in multi-root workspace, ie. allow the operations for each of the subprojects based on its apollo.config.js. It doesn't need to be handled in the same issue thought, and can be prioritised separately.

Anything more complex? Maybe later, if there're good use-cases. In my case, the multi-root env consists of react-apollo frontend, apollo-server backend, .net backend and docker-compose env, so I don't really need anything above the previous goals. My 2c.

[tsaiDavid]

Still experiencing this in our Lerna / Yarn Workspaces monorepos, with various client applications all with their individual apollo.config.js

[iamchathu]

Our project is structured as Lerna mono repo with multiple CRA projects which interacts with different graphQL endpoints. I have setup in apollo.config.js with

module.exports = {
  client: {
    service: {
      name: 'project-1-graphql',
      url: 'http://localhost:4001/graphql',
    },
  },
};

But haven't getting any intellisense for it.

[th-ko]

@JakeDawkins Any news on this one? Maybe this would help:
https://github.com/microsoft/vscode/wiki/Adopting-Multi-Root-Workspace-APIs#do-i-need-to-do-anything