This library has been replaced by @oclif/core and is no longer maintained
oclif / config Goto Github PK
View Code? Open in Web Editor NEWbase config object and standard interfaces for oclif components
License: MIT License
base config object and standard interfaces for oclif components
License: MIT License
This library has been replaced by @oclif/core and is no longer maintained
This is minor, but as someone who consumes this repo I get PRs via renovate that can surface the changelog from an incoming release. Would it be possible to have this repo create release notes so I can better understand what happens between versions?
Branch | Build failing π¨ |
---|---|
Dependency |
[ts-node](https://github.com/TypeStrong/ts-node)
|
Current Version | 6.1.2 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
ts-node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
Added
--files
) can be used to disable loading files from tsconfig.json
by defaultThere is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
Relates to twilio/twilio-cli#190
Requesting command args be passed with the command string when invoking command_not_found
hook:
Line 352 in 954ed2c
We seem to be getting a new error in the cli that seems to be related to this change:
We are seeing cases in the sfdx-cli when parent.children is undefined and this
results in the following error:
Installing dependencies for /Volumes/CaseAware/force-com-toolbelt... β’Ώ
(node:70974) TypeError Plugin: cli-engine: Cannot read property 'push' of undefined
module: @oclif/[email protected]
task: loadPlugins
plugin: cli-engine
root: /Users/tnoonan/tmp/node_modules/cli-engine
See more details with DEBUG=*
(node:70974) TypeError Plugin: cli-engine: Cannot read property 'push' of undefined
module: @oclif/[email protected]
task: loadPlugins
plugin: cli-engine
root: /Users/tnoonan/tmp/node_modules/cli-engine
Steps:
sudo rm -rf /usr/local/sfdx
sudo rm -rf /usr/local/lib/sfdx
sudo rm -rf /usr/local/bin/sfdx
sudo rm -rf ~/.local/share/sfdx ~/.config/sfdx ~/.cache/sfdx
sudo rm -rf ~/Library/Caches/sfdx
npm install sfdx-cli
This results in the error above.
We had a problem in this hook which is the same as the example, where options.id was undefined.
console.log(options.id); // returns undefined
console.log((options as any).Command.id); // returns command name
At first I thought that it could be a problem because I ran it on the init hook, but the official example is pretty much this.
Did I use it wrong?, Are the TS annotations wrong?
See this line:
import {CLIError, error, exit, warn} from '@oclif/errors'
@oclif/errors
must be declared as a dependency, not a devDependency. The only reason you aren't getting bitten by this (mostly) is because the current implementation of npm
and yarn
are shamelessly flattening the package hierarchy, thus hiding missing dependency declarations.
Line 109 in aedf35e
There may be a good reason for this warning but it appears to me to be spurious, or at least in the wrong place, given that:
["*"]
).I can see this was done intentionally but there's no extra context I can find to explain why.
https://github.com/oclif/config/blame/a3e3052c4acfece3acd66bab5a13ba7a32f7f6f9/src/ts-node.ts#L42
This means that typechecking doesn't happen during development, which obviously I can see the arguments for, in that it's gonna allow for faster iteration, but personally I'd prefer the command to just fail and force my team to fix their types. I don't know if that's a minority opinion, but if so I would appreciate this at least being somehow optional, perhaps by setting some field in package.json
, given that that's read from anyway?
I am not using the typescript option. Things worked fine in v1.12.0.
> ./bin/run
module.js:550
throw err;
^
Error: Cannot find module 'typescript'
at Function.Module._resolveFilename (module.js:548:15)
at Function.Module._load (module.js:475:25)
at Module.require (module.js:597:17)
at require (internal/module.js:11:18)
at Object.<anonymous> (/Users/xxx/sourcecode/service/node_modules/@oclif/config/lib/ts-node.js:5:22)
at Module._compile (module.js:653:30)
at Object.Module._extensions..js (module.js:664:10)
at Module.load (module.js:566:32)
at tryModuleLoad (module.js:506:12)
at Function.Module._load (module.js:498:3)
master
branch failed. π¨I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.
You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. Iβm sure you can resolve this πͺ.
Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.
Once all the errors are resolved, semantic-release will release your package the next time you push a commit the master
branch. You can also manually restart the failed CI job that runs semantic-release.
If you are not sure how to resolve this, here is some links that can help you:
If those donβt help, or if this issue is reporting something you think isnβt right, you can always ask the humans behind semantic-release.
semantic-release cannot push the version tag to the branch master
on remote Git repository.
Please refer to the authentication configuration documentation to configure the Git credentials on your CI environment.
Good luck with your project β¨
Your semantic-release bot π¦π
When trying to use oclif with a package manager such as Yarn 2, the following error message occurs:
(node:621147) Error Plugin: @maintainer/package: could not find package.json with {
type: 'core',
root: '/path/to/project/root',
name: '@oclif/plugin-help'
}
module: @oclif/[email protected]
task: loadPlugins
plugin: @maintainer/package
root: /path/to/project/root
See more details with DEBUG=*
Digging into the code, it seems pretty obvious that this is because of the fact that this package looks for plugins in node_modules
, but Yarn 2 doesn't use node_modules
.
Lines 109 to 135 in 07a0670
As per the Yarn 2 documentation, this is somewhat easily solved with a change to utilize resolve@>=1.9
. Any pitfalls or caveats existing contributors/maintainers can think of?
Yes, Yarn 2 is in RC stage but it will not be so eventually and this issue will need to be resolved. (Heh.)
I'm most probably going to try to fix this myself so I can obstinately use the new modules system, but tracking issues is important so I'm doing this first.
Is it feasible to include the Windows subsystem for Linux (WSL) as an additional literal in PlatformTypes
and resolve the platform
property in the config using the is-wsl
module as was done in your cli-ux
repo? WSL is currently resolving to Linux which is causing a strange edge case for some of our users.
master
branch failed. π¨I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.
You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. Iβm sure you can resolve this πͺ.
Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.
Once all the errors are resolved, semantic-release will release your package the next time you push a commit the master
branch. You can also manually restart the failed CI job that runs semantic-release.
If you are not sure how to resolve this, here is some links that can help you:
If those donβt help, or if this issue is reporting something you think isnβt right, you can always ask the humans behind semantic-release.
semantic-release cannot push the version tag to the branch master
on remote Git repository.
Please refer to the authentication configuration documentation to configure the Git credentials on your CI environment.
Good luck with your project β¨
Your semantic-release bot π¦π
master
branch failed. π¨I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.
You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. Iβm sure you can resolve this πͺ.
Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.
Once all the errors are resolved, semantic-release will release your package the next time you push a commit the master
branch. You can also manually restart the failed CI job that runs semantic-release.
If you are not sure how to resolve this, here is some links that can help you:
If those donβt help, or if this issue is reporting something you think isnβt right, you can always ask the humans behind semantic-release.
semantic-release cannot push the version tag to the branch master
on remote Git repository.
Please refer to the authentication configuration documentation to configure the Git credentials on your CI environment.
Good luck with your project β¨
Your semantic-release bot π¦π
I got the error from the title.
It is in lib/config.js:90:83
Introduced in the following commit
a23329a
if (!pjson.oclif) pjson.oclif = {schema: 1}
await this.loadPlugins(userPJSONPath, 'user', pjson.oclif.plugins.filter((p: any) => p.type === 'user'))
you set pjson.oclif
to { schema: 1 }
and then tries to call filter
on its property plugins
which is undefined
The CLI projects throws Cannot find module 'globby' error. Here's the error I'm getting when I simply run a command:
$ ./bin/run hello
(node:23379) [MODULE_NOT_FOUND] Error Plugin: my-test-cli: Cannot find module 'globby'
module: @oclif/[email protected]
task: not loading commands, globby not found
plugin: my-test-cli
root: /home/kabir/opensource/my-test-cli
See more details with DEBUG=*
Error Plugin: my-test-cli: Cannot find module 'globby'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
at Function.resolve (internal/modules/cjs/helpers.js:33:19)
at Plugin.get commandIDs [as commandIDs] (/home/kabir/opensource/my-test-cli/node_modules/@oclif/config/lib/plugin.js:64:40)
at Plugin._manifest (/home/kabir/opensource/my-test-cli/node_modules/@oclif/config/lib/plugin.js:151:28)
module: @oclif/[email protected]
task: not loading commands, globby not found
plugin: my-test-cli
root: /home/kabir/opensource/my-test-cli
This happened after I cleaned up my package.json file to contain only @oclif/*
and my core dependencies.
Here's my question - is this package globby
required to function any oclif based CLI application? If yes, then should it not be in oclif's dependencies
list? I didn't find it there.
Lines 7 to 12 in b0c2c9e
This means the user always needs to install globby
in their CLI, or else it won't work.
Please suggest if this was intentional or is an issue. If it is, then I guess moving this from your devDependencies
to dependencies
would solve it for us.
Thanks!
There is a bug in src/plugin.ts:readManifest()
If both oclif.manifest.json
and .oclif.manifest.json
are missing, the exception is caught and mistakenly silenced.
The nesting level of the this.warn
line might be wrong. No warning is issued if the .oclif.manifest.json
is missing too.
Possible fix?
if (!dotfile) return readManifest(true) else this.warn(error, 'readManifest').
} catch (error) {
if (error.code === 'ENOENT') { // both exceptions are caught here
if (!dotfile) return readManifest(true) // PROBLEM IS HERE
} else {
this.warn(error, 'readManifest')
}
}
From the context of a running command, there is no populated property indicating which plugin the command belongs to. We have BaseCommand
which has utilities used both by the CLI and plugins. I'd like it to be able to identify the plugin name/config in order to create a separate directory for placing assets so that plugins don't have conflicts when accessing these files.
Branch | Build failing π¨ |
---|---|
Dependency |
ts-node
|
Current Version | 6.0.5 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
ts-node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
Changed
declarationMap
option from input configuration under ts-node
The new version differs by 5 commits.
ee5c1b3
6.1.0
57f09b5
Remove declarationMap
from config (#602)
70d68ef
Document -T
alias in README (#600)
6c610b4
Use NODE=stable
tag over specific version (#598)
2e44bc0
Use ts.formatDiagnostics
over of custom function (#597)
See the full diff
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
master
branch failed. π¨I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.
You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. Iβm sure you can resolve this πͺ.
Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.
Once all the errors are resolved, semantic-release will release your package the next time you push a commit the master
branch. You can also manually restart the failed CI job that runs semantic-release.
If you are not sure how to resolve this, here is some links that can help you:
If those donβt help, or if this issue is reporting something you think isnβt right, you can always ask the humans behind semantic-release.
semantic-release cannot push the version tag to the branch master
on remote Git repository.
Please refer to the authentication configuration documentation to configure the Git credentials on your CI environment.
Good luck with your project β¨
Your semantic-release bot π¦π
@oclif/config Cannot find typescript { Error: Cannot find module 'typescript'
at Function.Module._resolveFilename (module.js:548:15)
at Function.Module._load (module.js:475:25)
at Module.require (module.js:597:17)
at require (internal/module.js:11:18)
at Object.<anonymous> (/Users/daghassi/git/cli/node_modules/@oclif/config/lib/ts-node.js:9:18)
at Module._compile (module.js:653:30)
at Object.Module._extensions..js (module.js:664:10)
at Module.load (module.js:566:32)
at tryModuleLoad (module.js:506:12)
at Function.Module._load (module.js:498:3) code: 'MODULE_NOT_FOUND' } +0ms
I assume this is an easy fix as right now typescript
is a dev dependency in this repo, and it needs to be a dependency
since this relies on it directly.
I'm not sure if this was the intended behavior or not, but I noticed recently while working with SFDX and TypeScript that the result of commands bubbles nearly all the way up to the caller - only to be abandoned here. I'm guessing that the intent was for the caller to implement postRun
to get explicit access to the result, but not all commands do, leaving result
to dangle at the penultimate moment.
For my current use-case (scanner:run
), I can get around this issue because that command itself can actually write to the filesystem, but it'd be vastly preferable to avoid the extra fs
work (and open up the flexibility of other commands' being more easily interacted with at the TypeScript-level).
Similar to oclif/command#59
Right now, I need to specify @oclif/parser
as a dependency of my CLI project, otherwise I encounter this error:
../../common/temp/node_modules/.registry.npmjs.org/@oclif/config/1.13.0/node_modules/@oclif/config/lib/command.d.ts:1:25 - error TS2307: Cannot find module '@oclif/parser'.
1 import * as Parser from '@oclif/parser';
~~~~~~~~~~~~~~~
Since the typedef of @oclif/config
depends on @oclif/parser
, it should really be a production dependency.
Branch | Build failing π¨ |
---|---|
Dependency | debug |
Current Version | 3.1.0 |
Type | dependency |
This version is covered by your current version range and after updating it in your project the build failed.
debug is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.
A long-awaited release to debug
is available now: 3.2.0
.
chrome.storage
(or make the storage backend pluggable): 71d2aa7supports-color@5
: 285dfe1enable()
(#517): ab5083fHuge thanks to @DanielRuf, @EirikBirkeland, @KyleStay, @Qix-, @abenhamdine, @alexey-pelykh, @DiegoRBaquero, @febbraro, @kwolfy, and @TooTallNate for their help!
The new version differs by 25 commits.
dec4b15
3.2.0
3ca2331
clean up builds
9f4f8f5
remove needless command aliases in makefile
623c08e
no longer checking for BROWSER=1
57cde56
fix tests
62822f1
clean up makefile
833b6f8
fix tests
ba8a424
move to XO (closes #397)
2d2509e
add .editorconfig
853853f
bump vulnerable packages
7e1d5d9
add yarn-error.log to .gitignore
e43e5fe
add instance extends feature (#524)
207a6a2
Fix nwjs support (#569)
05b0ceb
add Node.js 10, remove Node.js 4 (#583)
02b9ea9
Add TVMLKit support (#579)
There are 25 commits in total.
See the full diff
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
Greets,
I have to say I have been enjoying working with Oclif. It is going to allow me to complete a complex CLI project soon. What would be even better is being able to work with ES Modules (ESM) for the core CLI and plugin development. I personally along with folks like Sindre Sorhus are moving to ESM for all new Node releases imminently. Tooling needs to play catchup, but I like Oclif so much I spent a full day updating Oclif to support ESM along with maintaining CommonJS support. With my pull request it is possible to write core Oclif CLI code with ESM along with loading a mixture of ESM / CJS Oclif plugins. As noted at the bottom of the pull request I put up a separate Github repo w/ the compiled Typescript code that can be linked from Github to replace @oclif/config
enabling ESM support now.
I look forward to working on this pull request and getting things on the up and up for Oclif w/ ESM support.
Apologies for the double issue post here and in @oclif issues. I just figure posting there as well might reach a few more eyes in general.
When running oclif, I get the following error:
(node:83072) SyntaxError Plugin: stocli: Unexpected token import
module: @oclif/[email protected]
task: toCached
plugin: stocli
I have the latest versions installed.
import HelloWorld from '@src/commands/hello_world';
describe('fmt', () => {
it('writes the results to disk', async () => {
try {
await HelloWorld.run([]);
} catch (e) {
console.log(e);
}
expect({}).toMatchInlineSnapshot();
});
});
The above will fail in a typescript project due to config
setting up tsNode.register
. This is because Jest sees there's already a transformer for TypeScript, and so doesn't apply its own transformer.
This is "fine", except that the output of ts-node
doesn't match the output of Babel (which is what jest uses); when writing inline snapshots, jest looks for all toMatchInlineSnapshot
matchers by walking the ast as provided by Babel.
As such, it fails to find the snapshot matcher because while Babel is walking the AST, it didn't do the transformation, so the line numbers are different and it never finds the matcher.
In general, @oclif/config
probably shouldn't be using ts-node like this, as it's not really needed: it's encouraging users to ship TS files when they should be compiled, and this behaviour can be replicated in userland by calling tsNode.register
in your bin script, or by passing it to node
as part of the call (for when testing, which I assume is why this feature was added).
Additionally, it's probably going to cause oclif some pain when ESM modules land, as it'll likely force people to stick on commonjs.
Removing ts-node
would solve a number of issues that have been opened around oclif packages.
I was reading the docs and I was reading about the part about auto-updater in releasing section. It mentions that there are s3 templates that allow us to set url to any host that serves files in the dist folder built by oclif-dev pack command. But I don't see any templates here. Am I missing something here?
For reference it is written here
ts-node is in devDependencies of @oclif/config
however if I run CLI with DEBUG=* I see the following:
@oclif/config Error: Cannot find module 'ts-node'
@oclif/config Require stack:
@oclif/config - /Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/ts-node.js
@oclif/config - /Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/plugin.js
@oclif/config - /Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/config.js
@oclif/config - /Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/index.js
@oclif/config - /Users/arodik/projects/ffbt/node_modules/@oclif/command/lib/command.js
@oclif/config - /Users/arodik/projects/ffbt/node_modules/@oclif/command/lib/index.js
@oclif/config - /Users/arodik/projects/ffbt/dist/cli/entrypoint.js
@oclif/config at Function.Module._resolveFilename (internal/modules/cjs/loader.js:794:15)
@oclif/config at Function.resolve (internal/modules/cjs/helpers.js:80:19)
@oclif/config at registerTSNode (/Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/ts-node.js:19:32)
@oclif/config at Object.tsPath (/Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/ts-node.js:77:9)
@oclif/config at Plugin.get commandsDir [as commandsDir] (/Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/plugin.js:68:42)
@oclif/config at Plugin.get commandIDs [as commandIDs] (/Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/plugin.js:70:19)
@oclif/config at Plugin._manifest (/Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/plugin.js:161:28)
@oclif/config at async Plugin.load (/Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/plugin.js:56:25)
@oclif/config at async Config.load (/Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/config.js:28:9)
@oclif/config at async Object.load (/Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/config.js:334:5) +1ms
We don't use ts-node because we don't need it
Our package.json
4.17.10
to 4.17.11
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
lodash is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
10.10.0
to 10.10.1
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
Branch | Build failing π¨ |
---|---|
Dependency |
ts-node
|
Current Version | 6.0.3 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
ts-node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
Fixed
Buffer.from
instead of deprecated new Buffer
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
The root
property is calculated assuming the folder structure with node_modules
Line 109 in 71fb6d9
a project attempting to use Yarn Plug'n'Play fails to load with
could not find package.json with
Line 170 in e0b5e95
I can see that for my companies CLI, we are requiring all 13 commands up front. Does this make sense/is it necessary? The CLI has the command I want when I pass in a command. What is the need for requiring all the other commands if I'm not going to use them? In our case, this is adding almost 3s to initial startup time.
master
branch failed. π¨I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.
You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. Iβm sure you can resolve this πͺ.
Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.
Once all the errors are resolved, semantic-release will release your package the next time you push a commit the master
branch. You can also manually restart the failed CI job that runs semantic-release.
If you are not sure how to resolve this, here is some links that can help you:
If those donβt help, or if this issue is reporting something you think isnβt right, you can always ask the humans behind semantic-release.
semantic-release cannot push the version tag to the branch master
on remote Git repository.
Please refer to the authentication configuration documentation to configure the Git credentials on your CI environment.
Good luck with your project β¨
Your semantic-release bot π¦π
Repo:
Given the following topics list in the oclif package.json:
"topics": {
"t1": {
"description": "desc for t1",
"subtopics": {
"t1-1": {
"description": "desc for t1-1",
"subtopics": {
"t1-1-1": {
"description": "desc for t1-1-1"
},
"t1-1-2": {
"description": "desc for t1-1-2"
}
}
}
}
}
}
},
Then run ./bin/run t1 --help
.
Expected results:
USAGE
$ bin t1:COMMAND
COMMANDS
t1:t1-1 desc for t1-1
Actual results:
USAGE
$ bin t1:COMMAND
COMMANDS
t1:t1-1 desc for the first command in t1-1
Potential Fix
I debugged this a little big and narrowed it down to this line: https://github.com/oclif/config/blob/master/src/plugin.ts#L249
Specifically ${base}${input[k].name}
. It seems like what you want here is actually ``${base}${k}` since you are still dealing with the object, but not sure the original intent. The code looks like it wants a name property in the subtopic property but that seems counter-intuitive since I'm using a map. If I make the change locally, everything works fine, but I'm not sure if I am breaking another case.
If I have time, I'll try to create a PR.
1.4.0
to 1.4.1
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
fancy-test is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
The new version differs by 3 commits.
6a3c7ad
chore(release): 1.4.1 [skip ci]
d89fed0
fix: use generic tuples from ts3
33ae116
chore: updated lint config
See the full diff
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
Thanks for this project! It's been really useful to me. One thing I noticed is that it looks like the tsconfig.json is parsed here:
Lines 37 to 40 in 25ea412
and used in a few places, including here:
Lines 73 to 77 in 25ea412
However, if you have your oclif tsconfig.json extend another tsconfig.json (e.g. in a monorepo setup) like this:
tsconfig.json
{
"compilerOptions": {
"target": "es2016",
"esModuleInterop": true,
},
}
packages/my-oclif-project/tsconfig.json
{
"extends": "../../tsconfig.json",
"compilerOptions": {
"declaration": true,
"importHelpers": true,
"module": "commonjs",
"outDir": "lib",
"rootDir": "src",
"strict": true,
"noEmit": false,
},
"include": ["src"],
}
the "extends" is never followed, so the tsconfig does not inherit e.g. "target" and "esModuleInterop" from the base config. (About extending base configs: https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#tsconfig-bases)
Branch | Build failing π¨ |
---|---|
Dependency |
ts-node
|
Current Version | 6.0.4 |
Type | devDependency |
This version is covered by your current version range and after updating it in your project the build failed.
ts-node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
Fixed
normalize
for Windows to workThere is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
It looks like the only way to provide the configuration data is through package.json
https://github.com/oclif/config/blob/master/src/config.ts#L293
Can we add support for having an rc file?
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.