-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security: Migrate from colors.js to some other library, fork, or a vendor-ed alternative #57
Comments
I'd go for E and switch to |
Hey! I agree about switching to Something to take into account is that we need to allow passing custom colors by name via options (e.g |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A short-term fix to lock prettyjson to a non-corrupt version of colors.js was shipped in #54 🎉 Great work!
Open Question: What's the longterm plan?
I use
prettyjson
/colors
only as transitive dependencies, but I'm happy to contribute to make a long-term fix to prettyjson if you can explain which approach you prefer.Options
A. keep colors.js pinned at 1.4.0 forever (end-users may have dependabot constantly trying to upgrade the lib)
B. drop colors (but the colors are pretty!)
C. replace colors.js with a vendored/in-house implementation -- My casual look at
prettyjson
's source is that we just need compatible implementations ofcolors/safe::(green|red|grey)
. I'm not sure of the licensing compatibilities, but it feels like this shouldn't be a very complicated API surface area to replace.D. replace colors.js with a non-vulnerable fork. What fork should we pick?
E. replace colors.js with some other library. What library? -- chalk was suggested in #29
F. Do something else?
The text was updated successfully, but these errors were encountered: