You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Log output going to stdout does not need to match what's in the logs. It's way too repetitive.
Lot output customization would be helpful (basic templating like "{index} {level}: {subject}\n{message}"
urls should always be on their own line (good first output linting rule)
Linting is harder because unlike html the source is completely decoupled from the output. There's no source to meaningfully lint. It will have to be output testing. We already have a mock npm object that knows everything it sent to stdout. The teardown (or t.after) for that object is where we can start to do static analysis of cli output.
normal stdout does not need to be considered part of the semver contract (json and parseable still are of course)
markdown and commit messages should not have line length limits.
The text was updated successfully, but these errors were encountered:
Log output going to stdout does not need to match what's in the logs. It's way too repetitive.
Lot output customization would be helpful (basic templating like
"{index} {level}: {subject}\n{message}"
urls should always be on their own line (good first output linting rule)
Linting is harder because unlike html the source is completely decoupled from the output. There's no source to meaningfully lint. It will have to be output testing. We already have a mock npm object that knows everything it sent to stdout. The teardown (or t.after) for that object is where we can start to do static analysis of cli output.
normal stdout does not need to be considered part of the semver contract (json and parseable still are of course)
markdown and commit messages should not have line length limits.
The text was updated successfully, but these errors were encountered: