oclif / core Goto Github PK
View Code? Open in Web Editor NEWNode.js Open CLI Framework. Built by Salesforce.
Home Page: https://oclif.io
License: MIT License
Node.js Open CLI Framework. Built by Salesforce.
Home Page: https://oclif.io
License: MIT License
OS: mac os 12.2.1
Node Version: v16.13.1
CPU: arm64
The code of core/src/command.ts
is transpiled in JS in the following:
log(message = '', ...args) {
if (!this.jsonEnabled()) {
// tslint:disable-next-line strict-type-predicates
message = typeof message === 'string' ? message : (0, util_1.inspect)(message);
process.stdout.write((0, util_1.format)(message, ...args) + '\n');
}
}
jsonEnabled() {
return this.ctor.enableJsonFlag && this.argv.includes('--json');
}
The above code causes the following error:
TypeError: this.jsonEnabled is not a function
Is there a way to fix it?
A prompt with {type: "hide"}
option loops forever when input is redirected from /dev/null
.
To reproduce, create a program like:
const {CliUx} = require('@oclif/core')
CliUx.ux.prompt('Enter input', {type: "hide"})
Then run it taking stdin from /dev/null
. Or run npm i
and then ./prompt.js < /dev/null
in the attached project:
promptloop.zip
Actual behavior: the prompt loops forever.
Expected behavior: the prompt completes as no data is read (as it does without {type: "hide"}
).
Hey folks, I have the following setup, https://github.com/straw-hat-team/cli/tree/master/packages/cli which I am trying to convert to ESM
But I keep getting the following:
➜ react-hooks git:(master) DEBUG=* node ./node_modules/@straw-hat/cli/bin/run.js help
node:internal/process/esm_loader:94
internalBinding('errors').triggerUncaughtException(
^
Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/Users/ubi/Developer/github.com/straw-hat-team/cli/node_modules/@oclif/core/flush' imported from /Users/ubi/Developer/github.com/straw-hat-team/cli/packages/cli/bin/run.js
Did you mean to import @oclif/core/flush.js?
at new NodeError (node:internal/errors:371:5)
at finalizeResolution (node:internal/modules/esm/resolve:416:11)
at moduleResolve (node:internal/modules/esm/resolve:932:10)
at defaultResolve (node:internal/modules/esm/resolve:1044:11)
at ESMLoader.resolve (node:internal/modules/esm/loader:422:30)
at ESMLoader.getModuleJob (node:internal/modules/esm/loader:222:40)
at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:76:40)
at link (node:internal/modules/esm/module_job:75:36) {
code: 'ERR_MODULE_NOT_FOUND'
}
I fixed this by adding the extension to the import (is that required now?)
#!/usr/bin/env node
import oclif from '@oclif/core';
import flush from '@oclif/core/flush.js';
import handle from '@oclif/core/handle.js';
oclif.run().then(flush).catch(handle);
But then the commands don't seem to be working properly
➜ react-hooks git:(master) DEBUG=* node ./node_modules/@straw-hat/cli/bin/run.js help
config reading core plugin /Users/ubi/Developer/github.com/straw-hat-team/cli/node_modules/@oclif/core +0ms
config loadJSON /Users/ubi/Developer/github.com/straw-hat-team/cli/node_modules/@oclif/core/package.json +0ms
config loadJSON /Users/ubi/Developer/github.com/straw-hat-team/cli/node_modules/@oclif/core/oclif.manifest.json +0ms
config loadJSON /Users/ubi/Developer/github.com/straw-hat-team/cli/node_modules/@oclif/core/.oclif.manifest.json +0ms
config reading user plugins pjson /Users/ubi/.local/share/@oclif/core/package.json +0ms
config loadJSON /Users/ubi/.local/share/@oclif/core/package.json +0ms
config config done +0ms
config start init hook +0ms
config init hook done +1ms
config runCommand help [] +0ms
config start command_not_found hook +1ms
config command_not_found hook done +0ms
› Error: command help not found
➜ react-hooks git:(master)
Any idea of what the proper setup suppose to be for an ESM project? I can't find an example project of it.
Thanks in advanced,
Describe the bug
cli.ux.table is printing the words undefined
and null
and it'd be prettier if it was just left out
To Reproduce
pass objects to table with out
Expected behavior
omit undefined/null by default
Environment (please complete the following information):
darwin-x64 node-v16.15.1
I'm using the oclif generator (it's great, thanks!), but some of my commands are timing out when using the cli-ux flush implementation:
Line 132 in 858b40c
Any chance you'd be willing to take a PR with optional parameter?
ThankS!
Describe the bug
When there's a long running process using stdout, this will throw after 10s and break it:
Line 21 in f759fb1
Before version 1.9.7 it would silently catch it and let it continue:
v1.9.6...v1.9.7
To Reproduce
Concrete example:
We're using listr2 task inside a command to spawn process that takes a while to finish (compiling a rust project).
It pipes the stdout into task.stdout().
After 10 seconds, the process exits with an Error: timed out
Expected behavior
The process is not interrupted after 10 seconds.
Environment (please complete the following information):
Additional context
https://github.com/AstarNetwork/swanky-cli/blob/master/src/commands/compile/index.ts
Receiving this error when following the example in the README doc.
import { Command, flags } from "@oclif/core"
TS2724: '"../../node_modules/@oclif/core/lib"' has no exported member named 'flags'.
https://github.com/oclif/core/blob/main/src/index.ts#L24
Has an export named Flags
, is this the correct export? If so the main readme might need a quick update.
Describe the bug
If a custom base Command is defined WITH a custom init
method, then the --json
flag triggers the entire context to be logged.
To Reproduce
Steps to reproduce the behavior:
Define and use a custom base class with a custom init method.
// Base
export abstract class BaseCommand extends Command {
static _globalFlags = {
config: Flags.string({
description: 'Specify config file'
})
};
static flags = {}; // NOTE: Required otherwise _globalFlags is ignored.
async init (): Promise<void> {
await super.init();
const { flags } = await this.parse(BaseCommand); // THIS CAUSES THE PROBLEM
// Do custom init here based on global flag.
if (flags.config) {
this.userConfig = yaml.load(String(fs.readFileSync(configFile)));
}
}
}
// Command
export default class Status extends BaseCommand {
static enableJsonFlag = true;
async run (): Promise<{ status: number }> {
const status = 200;
this.log('Status:', status);
return { status: 200 };
}
}
Expected behavior
Invoking status --json
should output { status: 200 }
The actual output is:
▶ ./bin/dev cli status --json
{
"error": {
"oclif": {
"exit": 2
},
"parse": {
"input": {
"argv": [
"--json"
],
"context": {
"argv": [
"--json"
],
Environment (please complete the following information):
Additional context
--json
global flag never shows up in the help command output.Hi, would like to know if there are any plans for Yarn PnP support?
I'm currently working on a monorepo which uses yarn workspaces and PnP which is great. But I am not able to make oclif work.
While Yarn PnP is not yet supported, is there a possible hack/workaround to get oclif working using PnP mode?
I want to print the command level help when the command is run, I used to do something like this in the old version
import { flags} from '@oclif/command';
import Command from '../base';
export class Config extends Command {
static description = 'access configs'
static flags = {
help: flags.help({char: 'h'})
}
async run() {
await this._help();
}
}
In the new version, I don't think there is this._help()
function.
How can I get the same functionality in the new version?
Hi Philipe & Thomas (@RasPhilCo / @amphro) et al,
Great work on Oclif v2 Philipe and all involved. I really like the refactor to a core module compared to v1. Removing the circular dependencies (IE between v1 plugin-help and plugin-command) helps a bunch. I would like to discuss adding ES Module (ESM) support to Oclif v2 before initial launch in ~June. I initially prototyped the changes in v1 and saw the core announcement and have fully worked out the essential changes to @oclif/core for v2. I have a fork of @oclif/core with these changes and have fully implemented non-trivial Oclif middleware and resulting CLI w/ ESM to test everything out that is published on NPM using my @oclif/core fork. I also have three test repositories that have stripped down CLI tests with variations that respectively cover a wide swath of the 12.0.0 to 15.x Node ecosystem by Github Actions. I'll comment on this below in another post.
This kind of fundamental change is best in a new version of Oclif and is timely due to the minimum Node support of v12 for Oclif v2 which is the first Node LTS version that has wider support for ES Modules. Supporting ESM now future proofs Oclif as the larger Node ecosystem transitions to ESM in the coming years. There is a fair amount of movement in this direction already in April / May as Node 12 becomes the minimum LTS release. These changes do not affect current support of CommonJS / Typescript CLIs. In fact there could be some benefit for end user CLI development in Typescript as one could target ESM instead of CJS and if launching a CLI w/ Node 14 as a minimum version for support can target ES2020 for Typescript or simply write the CLI in ESM / ES2020. The main core Oclif v2 code should still of course target CJS for now, but this frees up end users to choose their target of choice between CJS / ESM / Typescript.
I will go over in more detail in a follow up post to this issue regarding what the changes cover and note the other areas of the larger codebase / other modules that require changes. I have already gone through several iterations of improving the essential changes and have arrived at what I think is a clean addition which I have tested across all the OS platforms w/ Node 12.0.0
- 15.x
. Beyond just submitting the pull requests / changes I am fully committed to helping write new tests / verifying Node 12.0.0 compatibility and assisting with writing documentation changes for v2. IE not just provide a code dump and add extra burden to any internal team members before the v2 launch. I believe there is enough time to get these changes in responsibly before the v2 ~June launch.
Instead of just making a pull request to @oclif/core I'd like to discuss willingness to add ESM support through my involvement first. In follow up posts to this issue I'll discuss the essential changes to @oclif/core and other modules (plugin-help / dev-cli / oclif / test). I'm 100% open to modifying anything necessary before / while making any pull requests. I look forward to working with the Oclif team to support ESM and make Oclif v2 a very solid solution for advanced CLI development on Node now and into the future.
I am unsure about the correct way of consuming secrets for some services. I want to provide a github api token to my oclif app, but have not found any documentation on this. I was considering using dotenv (with their dotenv.config()
syntax) but am unsure if this will work when I generate binaries.
Any help would be awesome
Hi, we have migrated our oclif CLI to the core version following the migration guide
Note: This error doesn't happen in the previous version
I'm having an error when executing any commands in development mode, in this way for example:
"scripts": {
"run:init": "NODE_ENV=development ./bin/run init"
}
When I run it using yarn: yarn run:init
I'm getting the following error:
(node:16497) [MODULE_NOT_FOUND] ModuleLoadError Plugin: @app/cli: [MODULE_NOT_FOUND] require failed to load /source/repos/cli/src/commands/init
module: @oclif/[email protected]
task: toCached
plugin: @app/cli
root: /source/repos/cli
Reviewing the code I saw that the error occurs in this method: resolvePath
Debugging error details:
Input values:
line 137 filePath = require.resolve(modulePath)
// it fails and enters to the catch
line 140 filePath = Config.tsPath(config.root, modulePath)
// filePath = /source/repos/cli/src/commands/init (It's okay)
In the previous line, It got the path to the typescrtipt files, and since the file has no extension,
in the line 145, It's append the supported extensions in the s_EXTENSIONS array to try to found it.
But since the '.ts' extension is not supported it can't find the file.
It's expected to build the following file path:
/source/repos/cli/src/commands/init.ts
Is that a bug? Or maybe there is something that I'm missing or misconfigured?
I look forward to your comments, thank you very much in advance!
Command has a log()
method for logging to stdout. Part of being a well-behaved CLI program is only logging stuff to stdout that might be consumed by another process, e.g. fed into another program's stdin. That means errors and other debug/status info should be printed to stderr. It would be nice if oclif commands supported this like they do with stdout via this.log()
As it stands, I have to use process.stderr
(which is what Command.log is doing under the hood for stdout)
Describe the bug
table throwing with large number of rows
To Reproduce
ORG_MAX_QUERY_LIMIT=1000000 ./bin/dev force:data:soql:query -u hub -q 'select id from scratchOrgInfo'
Expected behavior
print a table
Screenshots
error is ```
➜ plugin-data git:(cd/wait-end) ✗ ./bin/dev force:data:soql:query -u hub -q 'select id from scratchOrgInfo' > output.txt
Querying Data... done
ERROR running force:data:soql:query: Maximum call stack size exceeded
**Environment (please complete the following information):**
zsh 5.8.1 (x86_64-apple-darwin21.0)
**Additional context**
running a debugger--everything is fine until the call to `ux.table`
We have been using oclif v1 and unit test our CLI using jest. We follow the instruction in the oclif docs to use the static Command.run
inside tests. When attempting to migrate the project from v1 to core, several of the tests had timeout failures which signified a hanging handler. I dug into the parsing differences between v1 and core and found that core has a new feature which falls back to reading from stdin
if there are no arguments specified. This causes issues as our CLI has several commands which have only optional arguments. I am not aware of this being a known breaking change, as it isn't mentioned on the migration guide.
I believe a summary of the issue is that calling Command.run() without args under test causes a hang at this line in the parser (waiting for input that will never arrive).
Here is an example of one of our tests that is hanging with core.
await expect(AppRegisterCommand.run()).resolves.not.toThrow() // note the omitted run args
It fails with the following.
: Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.Timeout
The test just below it however passes on the same command since it includes args.
await expect(AppRegisterCommand.run([appId])).resolves.not.toThrow() // including any arg works around the hang
✕ calls selectFromList with correct config (5005 ms)
✓ calls correct endpoint for registration and logs success (18 ms)
"@oclif/core": "^1.0.11 "
darwin-x64 node-v12.18.1
Describe the bug
When we bump v1.13.0 to v1.13.4, TypeScript starts to complain that our Flags.integer()
with required: true
is parsed as number | undefined
(not number
) and can't be assigned to number
value. Previously, it seems the parsed flags
had any
type and TypeScript didn't complain. However, now it has parsed types but wrong type for Flags.integer()
with required: true
.
See annotations in this PR: https://github.com/autifyhq/autify-cli/pull/50/files
Note: Flags.string()
with required: true
is parsed properly and has string
type.
To Reproduce
static flags = {
"test-plan-id": Flags.integer({
required: true,
}),
"create-url-replacement-request": Flags.string({
required: true,
}),
};
public async run(): Promise<void> {
const { flags } = await this.parse(WebApiCreateUrlReplacement);
// flags["test-plan-id"] => number | undefined
// flags["create-url-replacement-request"] => string
Expected behavior
static flags = {
"test-plan-id": Flags.integer({
required: true,
}),
"create-url-replacement-request": Flags.string({
required: true,
}),
};
public async run(): Promise<void> {
const { flags } = await this.parse(WebApiCreateUrlReplacement);
// flags["test-plan-id"] => number
// flags["create-url-replacement-request"] => string
Environment (please complete the following information):
Linux 559abc3f4f3f 5.15.0-43-generic #46~20.04.1-Ubuntu SMP Thu Jul 14 15:20:17 UTC 2022 x86_64 GNU/Linux
GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu)
Additional context
N/A
We have a root CLI set up with a handful of plugin-plugins
that can be installed alongside it. Our root CLI currently has its own init
hooks that need be executed.
We now want to implement some init hooks within our plugin-plugins
. BUT, we want to ensure any plugin hooks are executed after the root CLI's hooks, because some of them are dependent on the setup that our root CLI provides.
In the short-term, we will likely implement a custom event (maybe called plugins:init
) that plugins can use to ensure they are executed after the root CLI has initialized. There are two downsides to this approach from what I can see:
I think it would be a bit cleaner to allow an option that ensures order is preserved. Is this a possible feature that could be implemented?
Hi, I'm receiving the following error with the lodash module whenever I run CliUx.ux.open
:
/Users/***/Projects/cliux-test/node_modules/@oclif/core/lib/cli-ux/open.js:62
if (lodash_1.default.isNumber(code) && code > 0) {
^
TypeError: Cannot read property 'isNumber' of undefined
at ChildProcess.<anonymous> (/Users/***/Projects/cliux-test/node_modules/@oclif/core/lib/cli-ux/open.js:62:34)
at Object.onceWrapper (events.js:421:26)
at ChildProcess.emit (events.js:314:20)
at maybeClose (internal/child_process.js:1022:16)
at Socket.<anonymous> (internal/child_process.js:444:11)
at Socket.emit (events.js:314:20)
at Pipe.<anonymous> (net.js:675:12)
The following code will reproduce the error:
import {CliUx} from "@oclif/core";
const run = async () => {
await CliUx.ux.open("https://www.google.com");
};
run().catch((err) => console.error(err));
Please note that the error goes away if I remove the .default
from the affected line in open.js
as follows:
if (lodash_1.isNumber(code) && code > 0) {
I was able to reproduce this on Node versions 12, 14 and 16. Is this a bug or am I importing modules incorrectly?
Describe the bug
Following the directions as best as I can but receive the following when trying to implement the CliUx package
TS2305: Module '"@oclif/core"' has no exported member 'CliUx'.
To Reproduce
Steps to reproduce the behavior:
import {Command, CliUx} from '@oclif/core'
export default class Do extends Command {
static description = 'Do thing'
async run(): Promise<void> {
CliUx.ux.action.start('Doing things')
CliUx.ux.action.stop(`Done!`)
}
}
Expected behavior
To be able to import the package as described in the documentation. Unsure if I'm missing something? I've looked into the core package and I can't see it, has it been removed?
Environment (please complete the following information):
Bug
I'm seeing all commands being required, both with ts-node and when using OCLIF_TS_NODE=0:
time DEBUG=* OCLIF_TS_NODE=0 npx mycli init --help
@oclif/config reading core plugin /Users/matthewshwery/dev/src/github.com/<repo>/packages/cli +0ms
@oclif/config loadJSON /Users/matthewshwery/dev/src/github.com/<repo>/packages/cli/package.json +0ms
@oclif/config loadJSON /Users/matthewshwery/dev/src/github.com/<repo>/packages/cli/oclif.manifest.json +3ms
@oclif/config loadJSON /Users/matthewshwery/dev/src/github.com/<repo>/packages/cli/.oclif.manifest.json +0ms
@oclif/config:@mycli/cli loading IDs from /Users/matthewshwery/dev/src/github.com/<repo>/packages/cli/dist/commands +0ms
@oclif/config:@mycli/cli found commands [ 'init', 'push', 'register', 'generate:action', 'generate:types' ] +10ms
@oclif/config:@mycli/cli require /Users/matthewshwery/dev/src/github.com/<repo>/packages/cli/dist/commands/init.js +2ms
@oclif/config:@mycli/cli require /Users/matthewshwery/dev/src/github.com/<repo>/packages/cli/dist/commands/push.js +317ms
@oclif/config:@mycli/cli require /Users/matthewshwery/dev/src/github.com/<repo>/packages/cli/dist/commands/register.js +225ms
@oclif/config:@mycli/cli require /Users/matthewshwery/dev/src/github.com/<repo>/packages/cli/dist/commands/generate/action.js +1ms
@oclif/config:@mycli/cli require /Users/matthewshwery/dev/src/github.com/<repo>/packages/cli/dist/commands/generate/types.js +186ms
@oclif/config reading user plugins pjson /Users/matthewshwery/.local/share/@mycli/cli/package.json +0ms
@oclif/config loadJSON /Users/matthewshwery/.local/share/@mycli/cli/package.json +789ms
@oclif/config loading plugins [ '@oclif/plugin-help' ] +3ms
@oclif/config loadJSON /Users/matthewshwery/dev/src/github.com/<repo>/packages/cli/package.json +3ms
@oclif/config loadJSON /Users/matthewshwery/dev/src/github.com/<repo>/packages/package.json +1ms
@oclif/config reading core plugin /Users/matthewshwery/dev/src/github.com/<repo>/node_modules/@oclif/plugin-help +0ms
@oclif/config loadJSON /Users/matthewshwery/dev/src/github.com/<repo>/node_modules/@oclif/plugin-help/package.json +0ms
@oclif/config loadJSON /Users/matthewshwery/dev/src/github.com/<repo>/node_modules/@oclif/plugin-help/oclif.manifest.json +1ms
@oclif/config:@oclif/plugin-help using manifest from /Users/matthewshwery/dev/src/github.com/<repo>/node_modules/@oclif/plugin-help/oclif.manifest.json +0ms
@oclif/config config done +2ms
@oclif/config start init hook +0ms
@oclif/config init hook done +1ms
mycli init version: @oclif/[email protected] argv: [ 'init', '--help' ] +0ms
Note: this happens across multiple commands, with and without --help
The documentation site claims that only the command to be executed will be required (emphasis mine):
The overhead for running an oclif CLI command is almost nothing. It requires very few dependencies (only 35 dependencies in a minimal setup—including all transitive dependencies). Also, only the command to be executed will be required with node. So large CLIs with many commands will load just as fast as a small one with a single command.
=> Found "@oclif/[email protected]"
=> Found "@oclif/[email protected]"
=> Found "@oclif/[email protected]"
=> Found "@oclif/[email protected]"
On macOS 11.4 (Big Sur), tried on multiple Node versions (12x/14x/16x), Yarn 1.22
Question, I have configured the topicSeparator with spaces.
My aliases look like the following:
static aliases = ['ls:policy', 'list:policy']
And the commands in the documentation are generated as expected:
If I run an alias command without params it works well. That is: oex ls policy
or oex list policy
But if I try to execute any of the two commands with parameters, for example: oex ls policy aws
. I get the error: command ls:policy:aws
not found.
Instead this does work by executing the following command: oex ls:policy aws
(as in oclif v1)
Could this be due to a problem in my configuration or is it a bug in oclif v2?
Executing this.error()
or this.exit()
inside an hook of any type (init, prerun ...) the terminal does not show any error message and the command is run ignoring the Error.
I've noticed this behavior after the migration from v1 to v2 and using the new package @oclif/core
.
Is this a bug or has changed the way to interrupt command from inside hooks in case of errors?
Thanks!
Describe the bug
Specifying enableJsonFlag after flags, causes the flags to not register. This worked fine in the last version I tried, 1.9.5, but has changed in 1.12.0.
To Reproduce
Steps to reproduce the behavior:
will only register the json flag
static flags = {
test: Flags.string()
}
static enableJsonFlag = true
will register both flags
static enableJsonFlag = true
static flags = {
test: Flags.string()
}
bug
The commands are being imported/declared before the init
hook.
I'm using i18next
to provide translations and proper internationalization to my CLI. It gives the t
function that returns a translation for the received key, but it only works after i18next is initialized. i18next initializes by calling its async method init
with some configuration.
I tried to initialize i18next
in the init
hook, but the init
hook executes after importing commands. And since commands are classes, their static properties are evaluated when the module is loaded, and using the t
function won't work.
class Example extends Command {
static description = t('commands.example.description');
// ...
}
In the snippet above Example.description
value will be undefined because i18next
isn't initialized.
The commands should be imported/declared after the init
hook.
@oclif/core
version 1.3.2.some types (number, integer, etc) have min/max values.
It would be nice if the help output displayed those.
Encountered issue when bundling with esbuild:
Error: Build failed with 1 error:
../../../common/temp/node_modules/.pnpm/@[email protected]/node_modules/@oclif/core/lib/errors/errors/cli.js:40:38: error: Could not resolve "../screen"
...20 lines omitted...
suggestion: ''
},
notes: [],
pluginName: '',
text: 'Could not resolve "../screen"'
}
],
warnings: []
}
ERROR: "build:esbuild" exited with 1.
Is there a reason you guys are mixing inline requires
with import
syntax? I've found this can cause a lot of issues in the past and can't see any obvious benefit?
https://github.com/oclif/core/blob/main/src/errors/errors/cli.ts#L36
https://github.com/oclif/core/blob/main/src/errors/errors/cli.ts#L49-L50
https://github.com/oclif/core/blob/main/src/errors/errors/cli.ts#L54
The last link is specifically the line that throws the error described, but I imagine there will be a lot of others once this is resolved if this one has managed to get through your CI / tests given that the ../screen
file doesn't exist.
See here for ../
directory (note the screen
file exists in the next level up):
This would be avoided by enforcing typescript-eslint/no-require-imports with a hard error
during build.
These inline requires are not handled well by the tsc
compiler whereas using top of page imports
will have definitely failed to build, alerting you to the error much sooner before publishing.
some flag properties (required, default, options) show up at the flag-level help.
It would be cool if dependsOn and exclusive did, too.
Right now, we rely descriptions (or errors) to tell the user what they should have done.
Hello,
I have recently upgraded my oclif
based cli from cli-ux
5.6.3 to 6.0.9.
Since then, I get the error mentioned in the issue title.
TypeError: this.options.sort.split is not a function
Since https://github.com/oclif/cli-ux is deprecated in favor of oclif/core, I have followed the migration steps as instructed here.
Unfortunately, I still get the same error.
Context
oclif
cli.table
/CliUx.ux.table
--sort
flag.Thanks for your help 🙏🏻
PS: Tell me any other information I can provide you to debug this error.
Given:
yarn link
then cd into mycli-plugin dir and run mycli plugins:link
.According to the documentation here, both foo and bar commands should come from mycli-plugin. However, only bar comes from mycli-plugin and mycli foo
continues to execute the foo.js file in mycli and mycli which foo
shows the mycli/core as the source for foo and mycli-plugin as the source for bar. Renaming mycli-plugin's foo.js to foo2.js immediately results in mycli having a new command, i.e., foo, foo2, and bar are all shown in --help and work as expected.
Presumably the override behavior has been changed or more likely there's a just a setup step to enable it that I've missed?
watermelon: flags.boolean({ default: true, allowNo: true }),
apple: flags.string({ exclusive: ['no-watermelon'] })
> cmd --no-watermelon --apple
[executes]
> cmd --no-watermelon --apple
Error: --apple= cannot also be provided when using --no-watermelon=
I'm using i18next
to provide CLI documentation in multiple languages but can't set it up properly.
init
hook runs after commands have been loaded (t
result in those cases is undefined
);bin/run
runs after commands have been loaded, but oclif readme
don't use it;Is there any configuration that I can use to set up i18next properly?
Heya!
I think I have a very specific usecase, I have a oclif cli app and to make the publication process a little easier, I created another oclif cli app which is responsible for running the chain of commands necessary for publication to S3 and promoting the release.
I run the commands in execa
. I tried child_process.exec()
as well as qqjs
which uses execa under the hood.
Whenever the oclif manifest
command gets called in yarn prepack
, the entire oclif pack tarballs
command fails, since the commandDir is resolved to /src/commands
instead of /dist/commands
like it should. I discovered this by adding a console log into plugin.js
into the get commandsDir()
function.
get commandsDir() {
console.log(this.pjson.name, ':', this.pjson.oclif.commands,(0, ts_node_1.tsPath), this.root, (0, ts_node_1.tsPath)(this.root, this.pjson.oclif.commands));
return (0, ts_node_1.tsPath)(this.root, this.pjson.oclif.commands);
}
The this.pjson.name
, this.pjson.oclif.commands
and this.root
get resolved properly, but instead of resolving to what the this.pjson.oclif.commands
returns, it resolves to /src/commands
Console log here:
oclif : ./lib/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli/node_modules/oclif /Users/steps/Projects/CLIS/ddm-cli/node_modules/oclif/lib/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
ddm-cli : ./dist/commands [Function: tsPath] /Users/steps/Projects/CLIS/ddm-cli /Users/steps/Projects/CLIS/ddm-cli/src/commands
Is there any way to fix this behaviour? The tsPath function resolves properly, the root path is proper, the oclif.commands is proper but for whatever reason tsPath is misbehaving
Also my exec function is
async exec(command: string, cwd: string): Promise<ExecaChildProcess> {
const options = {
shell: '/bin/zsh',
cwd,
env: process.env,
preferLocal: true,
};
return execa.command(command, options);
}
Hi there,
I'm trying to create an oclif CLI as an ESM package that uses typescript, but am having trouble with using commands with the .ts
extension. The CLI works fine if my command files are .js
files, but the minute I rename them to .ts
I get the following error:
$ ./bin/dev.js
(node:73944) [ERR_REQUIRE_ESM] Error Plugin: my-cli: Must use import to load ES Module: /cli/src/commands/create/index.ts
require() of ES modules is not supported.
require() of /cli/src/commands/create/index.ts from /cli/node_modules/@oclif/core/lib/module-loader.js is an ES module file as it is a .ts file whose nearest parent package.json contains "type": "module" which defines all .ts files in that package scope as ES modules.
Instead change the requiring code to use import(), or remove "type": "module" from /cli/package.json.
module: @oclif/[email protected]
task: toCached
plugin: my-cli
root: /cli
See more details with DEBUG=*
(Use `node --trace-warnings ...` to show where the warning was created)
The CLI
VERSION
my-cli/2.0.0 darwin-x64 node-v16.15.0
USAGE
$ cli [COMMAND]
TOPICS
plugins List installed plugins.
COMMANDS
help Display help for cli.
plugins List installed plugins.
I tried digging around in the module-loader doing things like adding the .ts
extension to s_EXTENSIONS
and the isPathModule()
method, but only seem to be digging a deeper hole. Does anyone have an example of how this is expected to work?
#!/usr/bin/env node
import oclif from '@oclif/core';
import path from 'node:path';
import url from 'node:url';
import { register } from 'ts-node';
const project = path.join(path.dirname(url.fileURLToPath(import.meta.url)), '..', 'tsconfig.json');
// In dev mode -> use ts-node and dev plugins
process.env.NODE_ENV = 'development';
register({ project });
// In dev mode, always show stack traces
oclif.settings.debug = true;
// Start the CLI
oclif
.run(void 0, import.meta.url)
.then(oclif.flush)
.catch(oclif.Errors.handle);
{
"name": "my-cli",
"version": "2.0.0",
"description": "The CLI",
"type": "module",
"exports": {
".": "./dist/index.js"
},
"files": [
"/bin",
"/dist",
"/npm-shrinkwrap.json",
"/oclif.manifest.json"
],
"bin": {
"cli": "./bin/run"
},
"oclif": {
"bin": "cli",
"dirname": "cli",
"commands": "./dist/commands",
"plugins": [
"@oclif/plugin-help",
"@oclif/plugin-plugins"
],
"topicSeparator": " "
},
"dependencies": {
"@oclif/core": "^1.8.2",
"@oclif/plugin-help": "^5.1.12",
"@oclif/plugin-plugins": "^2.1.0",
"ajv": "^8.11.0",
"axios": "^0.27.2",
"cli-table": "^0.3.11",
"execa": "^6.1.0",
"inquirer": "^8.2.4"
},
"devDependencies": {
"@oclif/test": "^2.1.0",
"@types/cli-table": "^0.3.0",
"@types/inquirer": "^8.2.1",
"prettier": "^2.6.2",
"shx": "^0.3.4",
"ts-node": "^10.7.0",
"typescript": "^4.6.4"
},
"scripts": {
"build": "shx rm -rf dist && tsc -b",
"lint": "eslint . --ext .ts --config .eslintrc",
"postpack": "shx rm -f oclif.manifest.json",
"posttest": "npm run lint",
"prepack": "npm run build && oclif manifest && oclif readme",
"version": "oclif readme && git add README.md"
}
}
import { Command } from '@oclif/core';
export default class CreateCommand extends Command {
static description = 'Create a new resource';
async run() {}
}
Hi guys, I'm trying to migrate bindl, but I'm having a really hard time.
It's a single command CLI (i.e. just calling bindl
would do the trick), but after following all the advices in the migration guide, it simply does not work.
Am I missing something?
# Before
❯ bin/run
› Error: I was not able to load the configuration file.
# After
❯ bin/dev
Downloads and extracts binaries from compressed packages using a config file
VERSION
bindl/2.0.0 wsl-x64 node-v16.15.1
USAGE
$ bindl [COMMAND]
Feature
Similar to how flags default are displayed in the help for a command, the help could also display the name of the environment variable when configured for a flag.
bin\run <command> --help
displays for each flags the default if configured, eg:
--my-flag=my-flag [default: my-default] Flag for ...
To find out the environment variable name that can be used instead of a flag, one must look at the code, or add manually the variable name to the flag's help.
Help could include the name of the environment variable, eg something like this:
--my-flag=my-flag [default: my-default, env: MY_FLAG] Flag for ...
We've been using oclif
for https://github.com/expo/eas-cli and it works really great! One thing we try to achieve in our CLI is the minimal package size. I mean we keep an eye on dependencies that we add to our package.json. One of the dependencies we especially try to avoid is lodash
. It weighs around 5 MB:
root@927d4ac7c00b:~/aaa# du -h --max-depth 1 node_modules/ | grep lodash
68K node_modules/lodash.merge
5.0M node_modules/lodash
Unfortunately, lodash
is one of the @oclif/core
dependencies. However, it seems it's not used in many places - https://github.com/oclif/core/search?q=lodash
From what I can see you only use two functions:
The first one should be pretty straightforward to re-implement. The second is not that easy to replace (but I'm not familiar with the codebase). I also saw this PR caaff0b where you replaced lodash.template
with lodash
and I'm quite not sure why because the PR description doesn't say too much about the motivation.
Do you think you could make oclif
even better and get rid of lodash
from dependencies? If yes, I'm a volunteer to work on the pull request.
Is your feature request related to a problem? Please describe.
I'm just getting started with oclif
and am already really enjoying it. However I find myself wanting more. Specifically I like the filter flag for the table, but don't seem to be able filter on anything other than a string contains. I looked at the source code for this, but I am also new to TypeScript
so, while I'm not 100% sure I'm not just making a mistake, I don't think the code has this capability, and at the moment it's probably a little over my head to make the PR for this functionality myself.
Describe the solution you'd like
$ my-cli command --filter "forks>=1"
Name Forks
───────────────── ─────
gene-actions-test 1
gene-test 2
Describe alternatives you've considered
I haven't found anything else at the moment. I could always preprocess that content, but in my mind defeats the purpose of having these handy flags.
Additional context
none
Being faced with errors is usual, but oclif's errors are not very helpful most of the time.
Either expose the root of the error more clearly. For instance I'm updating my CLI from v1 right now, and one of the subcommands is buggy and I really can't find any infos... here is the output (not asking for support on this I'll open a separate issue if needed, just to prove my point):
Running my cli subcommand:
DEBUG=* mtb resolve-to-nuke --help
config reading core plugin ~/mtb-cli +0ms
config loadJSON ~/mtb-cli/package.json +0ms
config loadJSON ~/mtb-cli/oclif.manifest.json +0ms
config loadJSON ~/mtb-cli/.oclif.manifest.json +0ms
config:@mtb/cli loading IDs from ~/mtb-cli/dist/commands +0ms
config:@mtb/cli found commands [ 'mono', 'resolve-to-nuke', 'mkthumbnail' ] +20ms
config:@mtb/cli (require) ~/mtb-cli/dist/commands/mono +15ms
config reading user plugins pjson /Users/mel/.local/share/mtb/package.json +0ms
config loadJSON /Users/mel/.local/share/mtb/package.json +0ms
(node:82496) [MODULE_NOT_FOUND] ModuleLoadError Plugin: @mtb/cli: [MODULE_NOT_FOUND] require failed to load ~/mtb-cli/dist/commands/resolve-to-nuke
module: @oclif/core@1.6.1
task: toCached
plugin: @mtb/cli
root: ~/mtb-cli
See more details with DEBUG=*
(Use `node --trace-warnings ...` to show where the warning was created)
ModuleLoadError Plugin: @mtb/cli: [MODULE_NOT_FOUND] require failed to load ~/mtb-cli/dist/commands/resolve-to-nuke
at Function.loadWithData (~/node_modules/.pnpm/@oclif+core@1.6.1/node_modules/@oclif/core/lib/module-loader.js:85:23)
at fetch (~/node_modules/.pnpm/@oclif+core@1.6.1/node_modules/@oclif/core/lib/config/plugin.js:181:83)
at Plugin.findCommand (~/node_modules/.pnpm/@oclif+core@1.6.1/node_modules/@oclif/core/lib/config/plugin.js:197:27)
at ~/node_modules/.pnpm/@oclif+core@1.6.1/node_modules/@oclif/core/lib/config/plugin.js:234:73
at Array.map (<anonymous>)
at Plugin._manifest (~/node_modules/.pnpm/@oclif+core@1.6.1/node_modules/@oclif/core/lib/config/plugin.js:232:58)
at async Plugin.load (~/node_modules/.pnpm/@oclif+core@1.6.1/node_modules/@oclif/core/lib/config/plugin.js:128:25)
at async Config.load (~/node_modules/.pnpm/@oclif+core@1.6.1/node_modules/@oclif/core/lib/config/config.js:86:9)
at async Function.load (~/node_modules/.pnpm/@oclif+core@1.6.1/node_modules/@oclif/core/lib/config/config.js:80:9)
at async Object.run (~/node_modules/.pnpm/@oclif+core@1.6.1/node_modules/@oclif/core/lib/main.js:44:20)
module: @oclif/core@1.6.1
task: toCached
plugin: @mtb/cli
root: ~/mtb-cli
See more details with DEBUG=*
config loading plugins [
'@oclif/plugin-help',
'@oclif/plugin-plugins',
'@oclif/plugin-autocomplete'
] +4ms
config reading core plugin ~/mtb-cli/node_modules/@oclif/plugin-autocomplete +0ms
config loadJSON ~/mtb-cli/node_modules/@oclif/plugin-autocomplete/package.json +0ms
config reading core plugin ~/node_modules/.pnpm/@oclif+plugin-help@5.1.12/node_modules/@oclif/plugin-help +0ms
config loadJSON ~/node_modules/.pnpm/@oclif+plugin-help@5.1.12/node_modules/@oclif/plugin-help/package.json +0ms
config reading core plugin ~/node_modules/.pnpm/@oclif+plugin-plugins@2.1.0/node_modules/@oclif/plugin-plugins +0ms
config loadJSON ~/node_modules/.pnpm/@oclif+plugin-plugins@2.1.0/node_modules/@oclif/plugin-plugins/package.json +0ms
config loadJSON ~/mtb-cli/node_modules/@oclif/plugin-autocomplete/oclif.manifest.json +0ms
config loadJSON ~/node_modules/.pnpm/@oclif+plugin-help@5.1.12/node_modules/@oclif/plugin-help/oclif.manifest.json +0ms
config loadJSON ~/node_modules/.pnpm/@oclif+plugin-plugins@2.1.0/node_modules/@oclif/plugin-plugins/oclif.manifest.json +0ms
config:@oclif/plugin-autocomplete using manifest from ~/mtb-cli/node_modules/@oclif/plugin-autocomplete/oclif.manifest.json +0ms
config:@oclif/plugin-help using manifest from ~/node_modules/.pnpm/@oclif+plugin-help@5.1.12/node_modules/@oclif/plugin-help/oclif.manifest.json +0ms
config:@oclif/plugin-plugins using manifest from ~/node_modules/.pnpm/@oclif+plugin-plugins@2.1.0/node_modules/@oclif/plugin-plugins/oclif.manifest.json +0ms
config config done +33ms
config start init hook +0ms
config init hook done +1ms
› Error: Command resolve-to-nuke not found.
Hi, we have migrated our oclif CLI to the core version following the migration guide
Locally it seems works as expected, I'm be able to run all the commands. But when I install the global version it doesn't work, does not found any command, specifically I have the following error message: "Error: command x not found"
I have these dependencies installed:
dependencies:
{
"@oclif/core": "^1.1.2",
"@oclif/plugin-help": "^5.1.10",
"@oclif/plugin-plugins": "^2.0.12"
}
And these are the oclif settings:
oclif:
{
"commands": "./lib/commands",
"bin": "test",
"plugins": [
"@oclif/plugin-help",
"@oclif/plugin-plugins"
],
"topicSeparator": " ",
"additionalHelpFlags": [
"-h"
],
"additionalVersionFlags": [
"-v"
]
}
Do you have any clue that it can't be happening?
Would be nice if there was a deno version of this!
Describe the bug
Flags typed as any in versions v1.12.0 & v1.12.1.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Flags are typed as with release v1.11.0 and before.
Environment (please complete the following information):
Additional context
Tested in Visual Studio Code
Hi,
After we bumped our CLI to @oclif/core, the tests are no longer running against the src/
folder. Instead, they are using the transpiled JavaScript from the lib folder.
This is absolutely fine for testing basic commands. However, mocking modules no longer works if the tested commands are coming from the lib/
and not the src/
folder.
When the tests are running, the environment variable NODE_ENV
is set to test
. Which will cause the method in src/util.ts#isProd
to always always return true
when running the tests, and therefore use the lib/
instead of the src/
folder.
Since I am not sure this condition was purposefully designed like this, I manually set NODE_ENV
to development
just before running the tests.
Should the method isProd()
also check if the NODE_ENV
is not equal to test
?
Thanks,
FYI, we are using Jest instead of mocha.
Report a bug
oclif rejects an empty string argument when a string argument is requried
Example code:
import {Command, flags} from '@oclif/command'
class Foo extends Command {
static description = 'describe the command here'
static args = [{name: 'file', required: true}]
async run() {
const {args, flags} = this.parse(Foo)
}
}
export = Foo
Example output:
$ ./bin/run
› Error: Missing 1 required arg:
› file
› See more help with --help
$ ./bin/run ''
› Error: Missing 1 required arg:
› file
› See more help with --help
$ ./bin/run 'foo'
$
The first error is expected (we omitted the argument). The second is not (we supplied an empty string as argument). In the 3rd case, the command succeeds as expected.
An empty string argument should be accepted.
I'm using oclif/command 1.8.0 on Ubuntu 20.04.
Feature
Whenever a flag is declared in a command with an environment field, it is still available as a normal flag for the command. The flag metadata only informs whether it was set from default or not.
In order to follow best practices regarding secret management, command flags containing secrets should only allow being inputted as environment variables. An envOnly
option should suffice. Alternatively, adding the origin of the value (default, command flag, environment variable, etc) in the flag metadata, so it can be verified during runtime, could also be an option.
A most recent merged PR for Typescript now better supports Node 12. In particular there is no need for the "semi-hack" used in module-loader.ts.
You can see discussion here and the PR here. When the latest Typescript version is available w/ this PR I'll look into adding module: node12
to tsconfig.json
and verify that import dynamic works correctly with the Oclif core build and remove the workaround.
A blog post about the Typescript 4.5 beta.
As we announced in this March blog post, we’re working on v1 of the new @oclif/core library, which we hope to release this summer.
We’ve pinned this issue to keep the community up to date on the remaining work to complete v1 and to update the existing oclif plugins and packages to use core. We’ll update this post as work is completed or new work is added.
Repository | Archive Repo | Determine If Still Requried | Add maitenance notification | Bump Engine to Node 14 | Ensure testing Node 14, 16 & latest & windows | Bump to typescript 4 | Migrate to Core | Major version bump |
---|---|---|---|---|---|---|---|---|
@oclif/plugin-autocomplete | n/a | n/a | n/a | required | required | required | required | required |
@oclif/plugin-command-snapshot | n/a | n/a | n/a | required | required | required | required | required |
@oclif/plugin-commands | n/a | n/a | n/a | required | required | required | required | required |
@oclif/plugin-help | n/a | n/a | n/a | required | required | required | required | required |
@oclif/plugin-interceptor | n/a | n/a | n/a | required | required | required | required | required |
@oclif/plugin-not-found | n/a | n/a | n/a | required | required | required | required | required |
@oclif/plugin-plugins | n/a | n/a | n/a | required | required | required | required | required |
@oclif/plugin-update | n/a | n/a | n/a | required | required | required | required | required |
@oclif/plugin-warn-if-update-available | n/a | n/a | n/a | required | required | required | required | required |
@oclif/plugin-which | n/a | n/a | n/a | required | required | required | required | required |
cli-ux | n/a | n/a | n/a | required | required | required | required | required |
color | n/a | n/a | n/a | required | required | required | required | required |
dev-cli | n/a | n/a | required | n/a | n/a | n/a | n/a | n/a |
docker | required | n/a | n/a | n/a | n/a | n/a | n/a | n/a |
eslint | n/a | n/a | n/a | required | required | required | required | required |
eslint-config-oclif | n/a | n/a | n/a | required | required | required | required | required |
eslint-config-oclif-typescript | n/a | n/a | n/a | required | required | required | required | required |
fancy-test | n/a | n/a | n/a | required | required | required | required | required |
fancy-test-nock | n/a | n/a | n/a | required | required | required | required | required |
node-linewrap | n/a | n/a | n/a | required | required | required | required | required |
nyc-config | n/a | n/a | n/a | required | required | required | required | required |
oclif | n/a | n/a | n/a | required | required | required | required | required |
screen | n/a | required | n/a | required | required | required | required | required |
semantic-release | n/a | required | n/a | required | required | required | required | required |
test | n/a | required | n/a | required | required | required | required | required |
fixpack | n/a | required | n/a | required | required | required | required | required |
open | n/a | required | n/a | required | required | required | required | required |
--help
logicpromote
should throw an error when no targets are foundpack
, promote
, and upload
commands publicThe code from Table's documentation page (from here) results in error:
async run() {
CliUx.ux.table(users, {...}, {
printLine: this.log, // <-- this is incorrect
...flags, // parsed flags
})
}
The error is:
TypeError: this.jsonEnabled is not a function
at Object.log [as printLine] (D:\projects\karamba\git\vcode\packages\cli-client\node_modules\@oclif\core\lib\command.js:80:19)
at Table.outputTable (D:\projects\karamba\git\vcode\packages\cli-client\node_modules\@oclif\core\lib\cli-ux\styled\table.js:234:21)
at Table.display (D:\projects\karamba\git\vcode\packages\cli-client\node_modules\@oclif\core\lib\cli-ux\styled\table.js:105:22)
at Object.table (D:\projects\karamba\git\vcode\packages\cli-client\node_modules\@oclif\core\lib\cli-ux\styled\table.js:279:39)
The correct example code is:
async run() {
CliUx.ux.table(users, {...}, {
printLine: this.log.bind(this), // <--
...flags, // parsed flags
})
}
I started converting my @oclif/core project from Common.js to ES modules, but unfortunately I reached a blocking point. It seems @oclif/core cannot load any of the index.js files under the commands folder. When running the CLI it prints the following error:
(node:49740) [ERR_REQUIRE_ESM] Error Plugin: @ngls/cli [ERR_REQUIRE_ESM]: require() of ES Module /Users/rpastro/ngls/ngls/cli/src/commands/elements/index.js from /Users/rpastro/ngls/ngls/cli/node_modules/@oclif/core/lib/module-loader.js not supported.
Instead change the require of index.js in /Users/rpastro/ngls/ngls/cli/node_modules/@oclif/core/lib/module-loader.js to a dynamic import() which is available in all CommonJS modules.
module: @oclif/[email protected]
task: toCached
plugin: @ngls/cli
root: /Users/rpastro/ngls/ngls/cli
All other files are successfully loaded by @oclif/core. The problem is only with the index.js files.
Looking into the code, the problem seems to be in the ModuleLoader.resolvePath
function. The modulePath parameter passed in case of index.js
is the folder name. For instance, if the command file is ".../commands/users/index.js", modulePath is set to ".../commands/users". Since this is a valid directory, fs.existsSync(filePath)
returns true and ModuleLoader.isPathModule
returns false since there is no extension in ".../commands/users" and we fall into the default branch.
I am trying to migrate to @oclif/core
for a CLI contained in a monorepo using yarn 3 as a package manager in order to try and use the oclif pack
functionality to package the CLI as an installer. You can see how I modified the package.json
for the CLI here - first question, do these changes look correct?
My issue is that when trying to run yarn oclif manifest
inside the CLI directory, I get the following error:
(node:246644) Error Plugin: oclif: could not find package.json with {
type: 'core',
root: '/home/strophy/Code/dashevo/platform/.yarn/cache/oclif-npm-2.1.0-2512c27eb7-b8c1c52405.zip/node_modules/oclif',
name: '@oclif/plugin-warn-if-update-available'
}
module: @oclif/[email protected]
task: loadPlugins
plugin: oclif
root: /home/strophy/Code/dashevo/platform/.yarn/cache/oclif-npm-2.1.0-2512c27eb7-b8c1c52405.zip/node_modules/oclif
See more details with DEBUG=*
(Use `node --trace-warnings ...` to show where the warning was created)
This dependency comes from "oclif": "^2.1.0"
and doesn't seem to be properly resolved by yarn. I tried adding the following to .yarnrc.yml
like this:
"@oclif/core@*":
dependencies:
"@oclif/plugin-warn-if-update-available": ^2.0.2
and/or
"oclif@*":
dependencies:
"@oclif/plugin-warn-if-update-available": ^2.0.2
But the error remains. Can anyone help identify what is going wrong here?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.