Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] How to launch a debugger #558

Closed
brandonkal opened this issue Oct 30, 2019 · 12 comments
Closed

[Question] How to launch a debugger #558

brandonkal opened this issue Oct 30, 2019 · 12 comments
Labels
external bug This issue highlights a bug in another project

Comments

@brandonkal
Copy link

How does one launch a debugger when using Yarn PNP.
Part of the issue may be:

  • VSCode does not yet support navigating to files in zip files. So I imagine this means unplugging all the packages.

However, I am having trouble understanding how to start a debugger with a pnp project. As node doesn't have support for yarn pnp, this did not work:

.vscode/launch.json

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "runtimeExecutable": "yarn",
      "name": "dev server",
      "cwd": "${workspaceFolder}",
      "runtimeArgs": ["start:debug"],
      "port": 5858
    }
  ]
}

package.json

{
  "name": "hot-typescript",
  "version": "1.0.0",
  "license": "MIT",
  "scripts": {
    "start": "webpack-dev-server --hot",
    "start:debug": "node --inspect-brk=5858 ./node_modules/.bin/webpack-dev-server --hot"
  },
  "devDependencies": {
    "@babel/core": "^7.6.0",
    "@babel/plugin-proposal-class-properties": "^7.5.5",
    "@babel/plugin-proposal-decorators": "^7.6.0",
    "@babel/preset-env": "^7.6.3",
    "@babel/preset-react": "^7.6.3",
    "@babel/preset-typescript": "^7.6.0",
    "@types/node": "^12.12.0",
    "@types/react": "^16.9.11",
    "@types/react-dom": "^16.9.3",
    "@types/webpack": "^4.39.5",
    "autoprefixer": "^9.7.0",
    "babel-loader": "^8.0.6",
    "babel-plugin-macros": "^2.6.1",
    "css-loader": "^3.2.0",
    "fork-ts-checker-webpack-plugin": "^1.5.0",
    "html-webpack-plugin": "^3.2.0",
    "mini-css-extract-plugin": "^0.8.0",
    "pnp-webpack-plugin": "^1.5.0",
    "postcss-loader": "^3.0.0",
    "postcss-nested": "^4.1.2",
    "ts-node": "^8.4.1",
    "typescript": "^3.6.3",
    "webpack": "^4.40.2",
    "webpack-cli": "^3.3.8",
    "webpack-dev-server": "^3.8.1"
  },
  "dependencies": {
    "@brandonkal/linaria": "^3.0.0-beta.8",
    "@hot-loader/react-dom": "^16.10.2",
    "@yarnpkg/pnpify": "^2.0.0-rc.7",
    "core-js": "^3.2.1",
    "react": "^16.9.0",
    "react-dom": "^16.9.0",
    "react-hot-loader": "^4.12.13",
    "regenerator-runtime": "^0.13.3"
  }
}

I didn't expect the above to work, as node doesn't understand yarn pnp, but that is where the test project is now.

Perhaps this hasn't yet been implemented, but I would like to debug my package to get it working in Yarn PNP.

@arcanis
Copy link
Member

arcanis commented Oct 30, 2019

That's an interesting question - I think Node currently has a quirk that prevents us from supporting --inspect-brk (and we should fix that!). The problem, if I remember correctly, is that when --inspect-brk is there Node will call require.resolve on the main entry point before executing the --require modules. Since before this point Zip archives cannot be opened, the resolution fails.

I think a fix would be to submit a PR to Node to do something like this. It will work because if the resolution fails then it's proof enough that we're not executing the main entry point anyway, and as soon as the resolution becomes available we get the correct result.

    if (!resolvedArgv) {
      // We enter the repl if we're not given a filename argument.
      if (process.argv[1]) {
        try {
          resolvedArgv = Module._resolveFilename(process.argv[1], null, false);
        } catch {}
      } else {
        resolvedArgv = 'repl';
      }
    }

    if (resolvedArgv) {
      // ...
    }

@brandonkal
Copy link
Author

That is interesting. I attempted to start webpack-dev-server directly through node without the
--inspect-brk flag, but the resolutions are rejected.

Does yarn add the --require flag transparently to scripts that call node? I see that it is executing the .pnp.js file.

Changing The script to this:

"start:debug": "node ./node_modules/webpack-dev-server/bin/webpack-dev-server.js --hot"

or

"start:debug": "node .yarn/.cache/webpack-dev-server-npm-3.9.0-e9c2d8aa12.zip/node_modules/webpack-dev-server/bin/webpack-dev-server.js --hot"

does not work. Looking through the .yarn/.cache/, that is the location of the bin.

@arcanis
Copy link
Member

arcanis commented Oct 30, 2019

The --require flag is passed through NODE_OPTIONS, so the second call should work (the first won't, however, since you don't have a node_modules directory).

Note that the best command line would be yarn run webpack-dev-server, tho. This way you don't need to make assumptions as to the path of the bin field (which isn't standardized).

does not work

What's the exact output?

@brandonkal
Copy link
Author

What's the exact output?

/Users/brandon/Documents/Code/linaria-pnp/.pnp.js:12647
        throw firstError;
        ^

Error: Couldn't find a suitable Node resolution for the specified unqualified path

Source path: /Users/brandon/Documents/Code/linaria-pnp/.yarn/.cache/webpack-dev-server-npm-3.9.0-e9c2d8aa12.zip/node_modules/webpack-dev-server/bin/webpack-dev-server.js
Rejected resolution: /Users/brandon/Documents/Code/linaria-pnp/.yarn/.cache/webpack-dev-server-npm-3.9.0-e9c2d8aa12.zip/node_modules/webpack-dev-server/bin/webpack-dev-server.js
Rejected resolution: /Users/brandon/Documents/Code/linaria-pnp/.yarn/.cache/webpack-dev-server-npm-3.9.0-e9c2d8aa12.zip/node_modules/webpack-dev-server/bin/webpack-dev-server.js.js
Rejected resolution: /Users/brandon/Documents/Code/linaria-pnp/.yarn/.cache/webpack-dev-server-npm-3.9.0-e9c2d8aa12.zip/node_modules/webpack-dev-server/bin/webpack-dev-server.js.json
Rejected resolution: /Users/brandon/Documents/Code/linaria-pnp/.yarn/.cache/webpack-dev-server-npm-3.9.0-e9c2d8aa12.zip/node_modules/webpack-dev-server/bin/webpack-dev-server.js.node

    at Object.makeError (/Users/brandon/Documents/Code/linaria-pnp/.pnp.js:10716:26)
    at resolveUnqualified (/Users/brandon/Documents/Code/linaria-pnp/.pnp.js:13157:35)
    at resolveRequest (/Users/brandon/Documents/Code/linaria-pnp/.pnp.js:13173:20)
    at Object.resolveRequest.maybeLog [as resolveRequest] (/Users/brandon/Documents/Code/linaria-pnp/.pnp.js:13208:32)
    at Function.module_1.default._resolveFilename (/Users/brandon/Documents/Code/linaria-pnp/.pnp.js:12639:37)
    at Function.module_1.default._load (/Users/brandon/Documents/Code/linaria-pnp/.pnp.js:12560:45)
    at Function.Module.runMain (internal/modules/cjs/loader.js:754:12)
    at startup (internal/bootstrap/node.js:283:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)

@arcanis
Copy link
Member

arcanis commented Oct 30, 2019

I think it's because you have an extra dot: should be .yarn/cache, not .yarn/.cache. One more reason to use the yarn run version 😉

@brandonkal
Copy link
Author

Yes. Good eye but the path ended up being more complex:

/Users/brandon/Documents/Code/linaria-pnp/.yarn/virtual/webpack-dev-server-virtual-98c281437e/0/cache/webpack-dev-server-npm-3.9.0-e9c2d8aa12.zip/node_modules/webpack-dev-server/bin/webpack-dev-server.js

I am not sure how yarn run would work with eventually passing debug flags to node.
This script works:

node $(yarn bin webpack-dev-server) --hot

I have confirmed that the above doesn't work with the --inspect-brk flag, so it looks like this is a matter of fixing node with something like you mentioned above.

@arcanis arcanis added the external bug This issue highlights a bug in another project label Nov 1, 2019
@arcanis
Copy link
Member

arcanis commented Jan 4, 2020

Should be fixed with my pr nodejs/node#30336, which I think shipped in Node 13.4

@arcanis arcanis closed this as completed Jan 4, 2020
@merceyz
Copy link
Member

merceyz commented Jan 4, 2020

I was able to get debugging with jest and ts-jest as well as ts-node to work, might work for webpack as well.

Leaving these here for other people that might come across this

Using jest:
https://github.com/merceyz/babel-plugin-optimize-clsx/blob/e713811651ce993d56d38b311939afcfa3059585/.vscode/launch.json#L7-L14
https://github.com/merceyz/babel-plugin-optimize-clsx/blob/e713811651ce993d56d38b311939afcfa3059585/jest.config.js#L8-L13

Using ts-node (not in a public repo):

{
  "type": "node",
  "request": "launch",
  "name": "Debug index",
  "skipFiles": ["<node_internals>/**", "node_modules/**"],
  "runtimeArgs": ["-r", "./.pnp.js", "-r", "ts-node/register"],
  "args": ["${workspaceFolder}/src/index.ts"],
  "cwd": "${workspaceFolder}"
}

@bartocc
Copy link
Contributor

bartocc commented Mar 5, 2020

➜ node --version
v13.10.1

➜ yarn --version
2.0.0-rc.29.git.20200303.cd90125a

I don't manage to launch a debug session with VSCode with the follwing launch.json

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "debug tests",
      "cwd": "${workspaceFolder}",
      "runtimeExecutable": "yarn",
      "port": 9229,
      "runtimeArgs": ["run", "--inspect-brk", "test"],
      "stopOnEntry": true
    },
  ]
}

VSCode cannot connect to the debug port.

Capture d’écran 2020-03-05 à 10 29 55

Is there anything I am doing wrong?

@valdestron
Copy link

valdestron commented Dec 4, 2020

I tested monorepo with pnp.js and zero-installs. Packages under .yarn/cache.
This configuration works correctly. I am able to debug my service and its tests.

I am using globally installed jest though, not sure how to use local one.
OS: OSX

// launch.json
{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Debug: service test",
      "skipFiles": ["<node_internals>/**", "node_modules/**"],
      "runtimeArgs": [
        "-r", 
        "../../.pnp.js", 
      ],
      "args": [
        "${env:HOME}/.npm-global/bin/jest", // global jest
        "--config",
        "${workspaceFolder}/packages/service/jest.config.js"
      ],
      "cwd": "${workspaceFolder}/packages/service"
    },
    {
       "type": "node",
       "request": "launch",
       "name": "Debug: service",
       "skipFiles": ["<node_internals>/**", "node_modules/**"],
       "runtimeArgs": ["-r", "./.pnp.js", "-r", "ts-node/register"],
       "args": ["${workspaceFolder}/packages/service/src/index.ts"],
       "cwd": "${workspaceFolder}"
    }
  ]
}

@merceyz
Copy link
Member

merceyz commented Dec 6, 2020

I am using globally installed jest though, not sure how to use local one.

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Launch via Yarn",
      "request": "launch",
      "runtimeArgs": [
        "jest",
        "--config",
        "${workspaceFolder}/packages/service/jest.config.js"
      ],
      "runtimeExecutable": "yarn",
      "cwd": "${workspaceFolder}/packages/service",
      "skipFiles": ["<node_internals>/**", "node_modules/**"],
      "type": "pwa-node"
    },
  ]
}

@adrian-gierakowski
Copy link

      "name": "Launch via Yarn",
      "request": "launch",
      "runtimeArgs": [
        "jest",
        "--config",
        "${workspaceFolder}/packages/service/jest.config.js"
      ],
      "runtimeExecutable": "yarn",
      "cwd": "${workspaceFolder}/packages/service",
      "skipFiles": ["<node_internals>/**", "node_modules/**"],
      "type": "pwa-node"

this worked for me (used with "type": "node")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
external bug This issue highlights a bug in another project
Projects
None yet
Development

No branches or pull requests

6 participants