question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Make flag sniffing optional

See original GitHub issue

Issuehunt badges

Although the heuristics for inspecting process.argv via hasFlag() are pretty reasonable, they are by no means foolproof and can lead to false positives and negatives. It would be nice if it were possible to use the functionality of supportLevel() without any of the hasFlag() logic. I believe the remaining logic would be a function of:

  • process.env.CI
  • process.env.TEAMCITY_VERSION
  • process.env. COLORTERM
  • process.env.TERM
  • process.stdout
  • process.platform

It would be even more flexible if it were possible to pass in the process object so that it could be mocked and/or used from another process.


IssueHunt Summary

qix- qix- has been rewarded.

Backers (Total: $40.00)

Submitted pull Requests


Tips

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Comments:10 (5 by maintainers)

github_iconTop GitHub Comments

1reaction
isaacscommented, Jul 17, 2016

I decided that actually most of what this module does is not quite what I want, and what I actually want is a similar concept but almost entirely different behavior, so I just wrote what I wanted in JS rather than try to describe it here 😃 https://github.com/isaacs/color-support

1reaction
isaacscommented, Jul 17, 2016

Another use-case: in node-tap you can pass --color to enable colors, and -c is a shorthand. I’d like to add support for --color=256 and also for -c256 as a shorthand, but if that means I’d have to either duplicate the work of supports-color, or conflict with it.

Also, reading the env for things like FORCE_COLORS is a nice default, but it can be weird. Most utilities have their own “turn colors on” type of environment variable, which is useful since you may not want an uncolored ls to pipe into a colored grep or whatever.

Basically, my preference would be for this module to determine whether colors should be by-default supported, but not whether the user has explicitly requested that they be turned on.

(“Well, then, Isaac, go make your own module for that” is a perfectly acceptable answer. The space for solutions is large 😉

Read more comments on GitHub >

github_iconTop Results From Across the Web

SQL Server 2016 Parameter Sniffing - SQLShack
Parameter sniffing is enabled by default in SQL Server, you can disable it by turning on the Trace Flag 4136 at the instance...
Read more >
Fixing parameter-sniffing of an embedded query via Recompile
One of my multi-step queries makes use of optional filters. Rather than using dynamic sql or if statements, I am attempting to use...
Read more >
Misconceptions on parameter sniffing - SQLServerFast
I recently saw a recommendation somewhere to always do this for every parameter in every stored procedure – which has the same effect...
Read more >
SQL Server 2016 Parameter Sniffing as a Database Scoped ...
Optimize for ad hoc workload; SET PARAMETERIZATION FORCED. We also have the option to disable parameter sniffing by enabling Trace Flag 4136 at ......
Read more >
EF 6 Parameter Sniffing - Stack Overflow
I have converted the entire query into LINQ to Entities and what I have found is that the SQL that it produces is...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found