ember-cli / console-ui Goto Github PK

JavaScript 100.00%

console-ui's Introduction

console-ui

The goal of this library is to declare a common interface that various node_modules can utilize allowing their UI interactions to be well coordinated and interoperable. This repo provides reference UI and test mock implementations. In theory, an alternate implementation abiding by the describe API could be provided, and the system and all participating libraries would continue to function correctly.

Features:

unified and pluggable input/output streams for all participants
system wide writeLevels enabling ability to easily silence/warn/debug print while abiding by shared configuration
unified progress
unified CI state (to disable CI unfriendly features such as progress spinners)
simple
test mock

Usage

const UI = require('console-ui')
const ui = new UI({
  inputStream: process.stdin,
  outputStream: process.stdout,
  errorStream: process.stderr,
  writeLevel: 'DEBUG' | 'INFO' | 'WARNING' | 'ERROR',
  ci: true | false
});

available write levels:

DEBUG (outputStream)
INFO (outputStream)
WARNING (errorStream)
ERROR (errorStream)

write to output:

ui.write('message');
ui.write('message', 'ERROR'); // specify  writelevel

write + newline to output:

ui.writeLine('message');
ui.writeLine('message', 'ERROR'); // specify  writelevel

write + newline to stderr;

ui.writeErrorLine('message');

write with DEBUG writeLevel

ui.writeDebugLine('message');

write with INFO writeLevel

ui.writeInfoLine('message');

write with WARN writeLevel

ui.writeWarnLine('message');

write a message related to a deprecation

ui.writeDeprecateLine('some message', true | false); // pass boolean as second argument indicating if deprecated or not

write an error nicely (in red) to the console:

if error.file || error.filename, nicely print the file name
- if error.line also nicely print file + line
- if error.col also nicely print file + line + col
if error.message, nicely print it
if error.stack, nicely print it

ui.writeError(error);

to adjust the writeLevel on the fly:

ui.setWriteLevel('DEBUG' || 'INFO' || 'WARNING' || 'ERROR');

to begin progress spinner \w message (only if INFO writeLevel is visible)

ui.startProgress('building...');

to end progress spinner

ui.stopProgress();

to prompt a user, via inquirer

ui.prompt(queryForInquirer, callback);

to query if a given writeLevel is visible:

ui.writeLevelVisible('DEBUG' || 'INFO' || 'WARNING' || 'ERROR'); // => true | false

console-ui's People

Contributors

Stargazers

Watchers

Forkers

jasonmit ro0gr toddjordan turbo87 zackthehuman limerentfox s3lase ykankaya rwjblue gabrielcsapo astronomersiva mike-north wondersloth pichfl chiragpat csprocket777 isabella232

console-ui's Issues

Action required: Greenkeeper could not be activated 🚨

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

restore spinner after output is done

https://github.com/ember-cli/console-ui/blob/master/lib/index.js#L40-L41

Follow and consider making use of Node 11.x's https://nodejs.org/api/report.html

--diagnostic-report-directory for node 11.x >= produces a pretty comprehensive error diagnostics file, similar to our own.

We should investigate possibilities.

Interesting highlights:

const report = process.report.getReport(new Error('custom error'));
> process.report.triggerReport();
https://nodejs.org/api/report.html#report_configuration

"uv_os_get_passwd" error during an Octane build in a docker image

I'm running a build in a docker image and am getting the following error which is killing the build process:

$ ember build -e=development
A system error occurred: uv_os_get_passwd returned ENOENT (no such file or directory)
(node:140) UnhandledPromiseRejectionWarning: SystemError [ERR_SYSTEM_ERROR]: A system error occurred: uv_os_get_passwd returned ENOENT (no such file or directory)
    at Object.userInfo (os.js:249:11)
    at summarizeProcess (/tmp/digitalization/teambuilder-frontend/node_modules/console-ui/lib/summarize-process.js:17:15)
    at writeError (/tmp/digitalization/teambuilder-frontend/node_modules/console-ui/lib/write-error.js:114:3)
    at UI.writeError (/tmp/digitalization/teambuilder-frontend/node_modules/console-ui/lib/index.js:167:20)
    at CLI.logError (/tmp/digitalization/teambuilder-frontend/node_modules/ember-cli/lib/cli/cli.js:318:13)
    at CLI.run (/tmp/digitalization/teambuilder-frontend/node_modules/ember-cli/lib/cli/cli.js:253:12)
    at process._tickCallback (internal/process/next_tick.js:68:7)
    at Function.Module.runMain (internal/modules/cjs/loader.js:834:11)
    at startup (internal/bootstrap/node.js:283:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:623:3)
(node:140) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:140) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Anyone solved this yet? If so, what was the solution?

Write error details to console in CI mode

If there are any issues encountered on CI machines having the path to the written error details file is nice, but unfortunately not helpful at all. (see e.g. https://travis-ci.org/EmberMap/ember-data-storefront/jobs/322981604#L3284)

Instead of printing the path to the file we should print the file contents if the CI environment variable is set.

document console-ui/mock

Some output being dropped since upgrading to `through2`

This was originally reported by @josemarluedke when he noticed TypeScript errors not being emitted, but after a little more investigation it looks like other output is missing as well.

In @josemarluedke's reproduction repo, running ember build only emits the following:

WARNING: ts-no-errors has added the class-properties plugin to its build, but ember-cli-babel provides these by default now! You can remove the transforms, or the addon that provided them, such as @ember-decorators/babel-transforms.

I can also briefly see the Building... spinner and cleaning up message, but those are quickly overwritten.

If I set a resolution for console-ui to 3.0.0 and rerun yarn, I see the full output I'd expect:

WARNING: ts-no-errors has added the class-properties plugin to its build, but ember-cli-babel provides these by default now! You can remove the transforms, or the addon that provided them, such as @ember-decorators/babel-transforms.
WARNING: ts-no-errors has added the class-properties plugin to its build, but ember-cli-babel provides these by default now! You can remove the transforms, or the addon that provided them, such as @ember-decorators/babel-transforms.
Environment: development
app/components/navigation.ts:4:3 - error TS2564: Property 'someArg' has no initializer and is not definitely assigned in the constructor.

4   someArg: boolean;
    ~~~~~~~

app/components/navigation.ts:6:7 - error TS2378: A 'get' accessor must return a value.

6   get shouldGiveAnError() {
        ~~~~~~~~~~~~~~~~~

app/components/navigation.ts:7:5 - error TS2349: Cannot invoke an expression whose type lacks a call signature. Type 'Boolean' has no compatible call signatures.

7     this.someArg();
      ~~~~~~~~~~~~~~

tests/integration/components/navigation-test.ts:15:18 - error TS2531: Object is possibly 'null'.

15     assert.equal(this.element.textContent.trim(), '');
                    ~~~~~~~~~~~~~~~~~~~~~~~~

tests/integration/components/navigation-test.ts:24:18 - error TS2531: Object is possibly 'null'.

24     assert.equal(this.element.textContent.trim(), 'template block text');
                    ~~~~~~~~~~~~~~~~~~~~~~~~

cleaning up...
Built project successfully. Stored in "dist/".

extractBroccoliError errors on broccoli 2

ES6 the codebase

classes
const / let
etc (but only stuff that support node => 4x

Version 10 of node.js has been released

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

Added the new Node.js version to your .travis.yml
The new Node.js version is in-range for the engines in 1 of your package.json files, so that was left alone

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

More information on this issue

Greenkeeper has checked the engines key in any package.json file, the .nvmrc file, and the .travis.yml file, if present.

engines was only updated if it defined a single version, not a range.
.nvmrc was updated to Node.js 10
.travis.yml was only changed if there was a root-level node_js that didn’t already include Node.js 10, such as node or lts/*. In this case, the new version was appended to the list. We didn’t touch job or matrix configurations because these tend to be quite specific and complex, and it’s difficult to infer what the intentions were.

For many simpler .travis.yml configurations, this PR should suffice as-is, but depending on what you’re doing it may require additional work or may not be applicable at all. We’re also aware that you may have good reasons to not update to Node.js 10, which is why this was sent as an issue and not a pull request. Feel free to delete it without comment, I’m a humble robot and won’t feel rejected 🤖

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴