createProjectGraph() doesn't work using runNxCommandAsync()

[Brian-McBride]

Current Behavior

I am using the plugin generator.

await runNxCommandAsync(`build ${plugin} --skip-nx-cache`);

Overall, the generator seems really easy to use. Out of the box, it works.

Then, I want to follow the conventions set up in @nrwl/node as I'm doing a builder very similar. Of course, the e2e tests are way more complicated there. And might know why

If you just try to do this:

export function esbuildExecutor(
  rawOptions: BuildExecutorSchema,
  context: ExecutorContext
) {
  const projGraph = createProjectGraph();
  conole.log(projGraph) // take a peek
  return Promise.resolve({ success: true }) ​
}

The projGraph value will be set to the outer project, not the generated ./tmp/nx-e2e/proj where it is expected.

Expected Behavior

Within e2e tests, createProjectGraph should return data about the testing project, not the parent plugin project.

Steps to Reproduce

I think the sample above shows the code.
Just use the nx tools to create new plugin library, then, then try to use createProjectGraph when running your e2e tests. You'll see that it give you the graph for the root project, not the temp one you created in the temp folder.

My guess, based not eh completely different test code running in the @nrwlnode tests, is that the CWD is not being set correctly somewhere in that pipeline.

[Brian-McBride]

Oh, yeah. I thought, well, heck, I should just copy over the tests that clearly work in the nx repo.

@nrwl/e2e/utils isn't something that seemed exported or published anywhere?

The dev tools work is great. I could see a lot more adoption by my teams. I think it would help to have more results in the tools. How do you get the tree for ./tmp/nx-e2e/proj?

My end goal is to check dependencies for some stages of my build process. When I saw what was happening in @nrwl/node I was thinking, "oh, making sure you have built the supporting packages... smart"....

[simondotm]

I've just been caught out by this as well. e2e testing my plugin, I call createProjectGraph() in one of my plugin executors to get dependencies, but it returns the graph for the parent workspace, not the e2e workspace.
The nxdeps.json file in the e2e workspace node_modules/.cache folder is correct.

[simondotm]

Fwiw, the context.root directory and context.workspace passed into my executor is correct.

Also I see the same issue if I run my executor from the command line, so it doesnt seem to be a test environment thing.

[simondotm]

Ok a bit more digging... (apologies if streamed updates are not conventional)
const projGraph = createProjectGraph(); has 3 default parameters:
readWorkspaceJson(), readNxJson(), readWorkspaceFiles()

These do not return the correct objects when called inside my executor - If I log them, I see right away they are the parent workspace, not the e2e workspace.

  console.log("readWorkspaceJson=", JSON.stringify(readWorkspaceJson(), null, 3))
  console.log("readNxJson=", JSON.stringify(readNxJson(), null, 3))
  console.log("readWorkspaceFiles=", JSON.stringify(readWorkspaceFiles(), null, 3))

[simondotm]

Ok setting environment variable NX_WORKSPACE_ROOT_PATH to the e2e workspace root corrects the issue, and my executor now gets the correct project graph. Its not a fix, just an observation.
Now squinting at: https://github.com/nrwl/nx/blob/d007d37fb4f625fc4854d06d2e083ed778d6a3db/packages/workspace/src/utilities/app-root.ts

[simondotm]

ok this is strange: pathInner() function in app-root uses __dirname as a starting point to unwrap parent directories until it hits a workspace.json or angular.json
Since __dirname is the script being currently run, I console logged this from my executor in the e2e workspace and it revealed the dist\packages\<plugin>\src\executors\<executor> script folder, not the node_modules folder in the e2e workspace that I expected to see. So that explains why we get the parent workspace graph, not the e2e plugin graph - it's working back from the wrong starting directory.

(my plugin is correctly installed in the tmp\nx-e2e\proj\node_modules folder btw)

[simondotm]

And now of course I realize the e2e workspace package.json has my plugin as a local file reference, so that explains the __dirname:
"@myorg/myplugin": "file:<pathto>\\myplugin/dist/packages/myplugin"

not sure where to go next with this. :/

[simondotm]

@Brian-McBride I've monkey patched a solution for now. In my plugin executor (or whereever) I import the following module, which checks if cwd is an nx-e2e folder and sets the NX_WORKSPACE_ROOT environment var for that runtime. This worked for me to ensure the correct project graph is returned, and has the desired workaround effect of letting me make progress with my plugin development at the moment.
utils/e2ePatch.ts

// monkeypatch to ensure nx plugin e2e tests have the correct workspace for createProjectGraph()
// https://github.com/nrwl/nx/issues/5065
import * as path from 'path';
import * as fs from 'fs';
function patchAppRoot() : string {
    const cwd = process.cwd()
    const e2e = cwd.includes('nx-e2e')
    function pathInner(dir: string): string {
        if (process.env.NX_WORKSPACE_ROOT_PATH)
            return process.env.NX_WORKSPACE_ROOT_PATH;
        if (path.dirname(dir) === dir) return cwd;
        if (
            fs.existsSync(path.join(dir, 'workspace.json')) ||
            fs.existsSync(path.join(dir, 'angular.json'))
        ) {
            return dir;
        } else {
            return pathInner(path.dirname(dir));
        }
    }
    const appRoot = pathInner(cwd)

    console.log("cwd=" + cwd)
    console.log("is e2e=" + e2e)
    console.log("appRoot=" + appRoot)

    //only patch the workspace rootpath if we are running in an nx-e2e workspace path
    if (e2e) {
        process.env.NX_WORKSPACE_ROOT_PATH = appRoot
        console.log("e2e appRoot PATCHED from __dirname '" + __dirname + "' to '" + appRoot + "'")
    }
    return appRoot
}
export const e2eAppRoot = patchAppRoot()

In your plugin executor as the first import (before calling anything that sets appRoot)
import '../../utils/e2ePatch' // intentional side effects

[simondotm]

Also, linking to a related issue #4157

[AgentEnder]

@Brian-McBride Does this still occur w/ latest Nx?

[Brian-McBride]

@AgentEnder I haven't had the time to test it. I created an e2e test around the issue and haven't thought about it since.
I can try to get to that project this week sometime and check it out though.

[github-actions]

This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
If we missed this issue please reply to keep it active.
Thanks for being a part of the Nx community! 🙏

[tbinna]

@AgentEnder this issue still exists for me in Nx 13.9.4. In my case exposed when running e2e tests that invoke a custom build executor (we have been chatting about this over on Slack).

Setting NX_WORKSPACE_ROOT_PATH to the e2e workspace root in the e2e test and using the patch posted by @simondotm resolved the issue. As already highlighted by Simon, the issue seems to be ultimately caused by the call to __dirname in app-root.ts

[simondotm]

For various reasons I had to regress a workspace to nx 13.10.6 and got hit by this issue again, gah.

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.