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

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

Is there documentation somewhere on how to get it working with a non-multi-root-but-still-client-folder-server-folder setup?

@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.

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

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

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'],
  },
}

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.

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

It is shocking that this has not been fixed yet, this is a great tool but not supporting multi root workspaces – which is very common for modern dev orgs – is really painful.

You don’t need a monorepo to experience this issue. A normal “client/server” folder structure is enough to make the extension fail. The solution will be to read the paths relative to the apollo.config.js file, and that will solve 99% of the problems. The apollo cli already does this.

@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 😬😬

Friends, any workarounds? I don’t have @digeomel 's situation. Just a Workspace with multiple project folders in it. One of them has an apollo.config.js file. I need to keep another file in the root of this project called schema.json and keep another one for usage with Apollo. So I do this:

module.exports = {
  client: {
    name: 'Zvook Webapp Client',
    service: {
      name: 'zvook-main-graph',
      url: 'https://localhost:4000/dev/graphql',
      skipSSLValidation: true,
      localSchemaFile: './apolloGraphQLSchema.json',
    },
    includes: ['./src/**/*.queries.ts'],
    excludes: [
      '.storybook/**/*',
      '.vscode/**/*',
      'build/**/*',
      'public/**/*',
      '.editorconfig',
      '.env*',
      '.eslint*',
      '.gitignore',
      '.prettier*',
      'buildspec*',
      '*.md',
      '*.json',
      '*.log',
      '*.lock',
    ],
  },
};

Here’s my error:

CLIError: Error in "Loading schema for MYREMOTEGRAPHNAME": Error: Unable to read file ./apolloGraphQLSchema.json. ENOENT: no such file or directory, open './apolloGraphQLSchema.json'

Given the ‘freshness’ of this issue, I’m not expecting too much help here but would take any potential clues as to where to keep digging deeper.

Cheers!

I think I have found a temporary workaround. Let’s say your have two projects under your root folder, so it’s like root/projects/projA and root/projects/projB. The schema.graphql and the apollo.config.js files are already there under root (and of course it doesn’t work in the sub-projects).

The solution is to copy both files under each sub-project, and then I add those folders to the vscode workspace (in addition to the existing root one). When you add the individual folders in the workspace, vscode seems to treat them as separate projects, and it works without any noticeable side-effects. Actually I didn’t try the 2nd sub-project, but if it doesn’t work, you can just create different workspaces for each sub-project.

Apollo complains about duplicate schema definitions, but in the end works fine. It’s a hack, but it seems to work, for me at least.