oclif / core

Node.js Open CLI Framework. Built by Salesforce.

Home Page:https://oclif.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

`bin/dev` does not work as intended after upgrading to @oclif/core to V3

wataruian opened this issue · comments

Describe the bug
After upgrading @oclif/core to V3, running bin/dev <command> does not work as intended and requires a build for changes to take effect. It now behaves similarly to bin/run.

To Reproduce
Steps to reproduce the behavior:

  1. Make changes to a command (console.log('anything') will do) without build
  2. Run using bin/dev
  3. See the changes won't take effect unless rebuilt

Expected behavior
Should behave as bin/dev and not be similar to bin/run

Screenshots
N/A

Environment (please complete the following information):

  • MacOS Ventura (ARM64)
  • Node Version: v18.15.0
  • Yarn Version: 3.6.3

Additional context

  1. bin/dev works fine on my previous version "@oclif/core": "^2.15.0",
  2. I am using Yarn PnP

@wataruian I'm not seeing this happen on a newly generated CLI (either from the CJS template or the ESM template)

Can you create a simple repository that replicates the issue? It'd also be helpful if you provided the logs from setting the DEBUG=config:ts-node environment variable. That should tell us why it's skipping the compilation step. Thanks!

I can't easily reproduce the repo since I am using a large monorepo, but for context:

I tried creating a new command that just do console.log() and it works just fine.

But I am getting an issue when the command actually uses lodash - isNil().

module: @oclif/core@3.3.0
task: cacheCommand
plugin: @wataruian/cli
root: /Users/wataruian/monorepo/packages/cli
See more details with DEBUG=*
TypeError Plugin: @wataruian/cli: Cannot read properties of undefined (reading 'isNil')
    at Object.<anonymous> (/Users/wataruian/monorepo/packages/cli/src/configs/project.ts:83:12)
    at Module._compile (node:internal/modules/cjs/loader:1254:14)
    at Module.m._compile (/Users/wataruian/monorepo/.yarn/__virtual__/ts-node-virtual-6f9ee5be06/0/cache/ts-node-npm-10.9.1-6c268be7f4-090adff130.zip/node_modules/ts-node/src/index.ts:1618:23)
    at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
    at require$$0.Module._extensions..js (/Users/wataruian/monorepo/.pnp.cjs:45357:33)
    at Object.require.extensions.<computed> [as .ts] (/Users/wataruian/monorepo/.yarn/__virtual__/ts-node-virtual-6f9ee5be06/0/cache/ts-node-npm-10.9.1-6c268be7f4-090adff130.zip/node_modules/ts-node/src/index.ts:1621:12)
    at Module.load (node:internal/modules/cjs/loader:1117:32)
    at Function.Module._load (node:internal/modules/cjs/loader:958:12)
    at Function.require$$0.Module._load (/Users/wataruian/monorepo/.pnp.cjs:45202:31)
    at Module.require (node:internal/modules/cjs/loader:1141:19)

I tried recreating the issue on a repo with just single package but using lodash seems to work there. So it is hard to pinpoint the actual issue.

But the line that is having the issue is just checking if the env var is existing and assigns a value:

const value = !_.isNil(process.env['TEST_VALUE']) ? process.env['TEST_VALUE'] : 'some-test-value';

I am not sure if the issue is with oclif, lodash, ts-node, workspaces or pnp itself (too many factors to consider).

Feel free to close this issue. I'll try to reproduce and debug on my end.

@wataruian Thanks - feel free to reopen the issue if you trace it down to something in oclif

@mdonnalley it's weird, doing yarn cache clean && yarn install and rerunning the command works on my mono repo now. 😄

We can close this officially.