Skip to content
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

5.x Roadmap #656

Open
3 of 11 tasks
Qix- opened this issue Dec 19, 2018 · 19 comments
Open
3 of 11 tasks

5.x Roadmap #656

Qix- opened this issue Dec 19, 2018 · 19 comments
Assignees
Labels
discussion This issue is requesting comments and discussion help-wanted This issue has an actionable item
Milestone

Comments

@Qix-
Copy link
Member

Qix- commented Dec 19, 2018

5.x Roadmap

It's about time for another step in bringing debug up to date - the 5.x major release.

I know it hasn't been a long time since 4.x was released, and I'm aware that its release kind of forced.. pushed.. nudged users to update their best practices.

Here's what to expect from the 5.x release:

@Qix- Qix- added discussion This issue is requesting comments and discussion help-wanted This issue has an actionable item labels Dec 19, 2018
@Qix- Qix- added this to the 5.x milestone Dec 19, 2018
@Qix- Qix- pinned this issue Dec 19, 2018
@Qix- Qix- self-assigned this Dec 19, 2018
@OllieJennings
Copy link

Any chance we can get the issue fixed where you have

.env

DEBUG=*

And you run babel-node -r dotenv/config ./index.js

As right now this won't work

@Qix-
Copy link
Member Author

Qix- commented May 15, 2019

@OllieJennings #705 please search next time.

@botond-veress
Copy link

@OllieJennings, that issue was closed prematurely, but it is not fixed. I switched back to debug@3 until the issue will get some attention and will be fixed. I suggest you to do the same thing.

@debug-js debug-js deleted a comment May 18, 2019
@Qix-
Copy link
Member Author

Qix- commented May 18, 2019

Please, there's no reason to post in two separate places about a closed ticket. Keep all discussion about that there - posting on the roadmap issue isn't going to get my attention any faster, I look at all issues regardless of urgency.

@getsnoopy
Copy link

Just to confirm, the 5.x roadmap stipulates that the module will use console.debug for Node.js environments as well, correct? The description in the OP here is different than that of the linked issue.

@Qix-
Copy link
Member Author

Qix- commented Jul 26, 2020

@getsnoopy It'll be configurable. If you want to use something other than console.debug you would make your own log handler. That's defined in #556.

@suiyun39
Copy link

If remove build system, How to also supports esm and cjs module?
When used in nodejs, in most cases no bundle tools, requires the library to provide two versions of the export.

like this:

"exports": {
  ".": {
    "import": "./dist/my-lib.mjs",
    "require": "./dist/my-lib.umd.js"
  }
}

@FossPrime
Copy link

FossPrime commented Jun 5, 2023

I ended up doing a complete rewrite and adding Deno support by accident while trying to add ESM support.

I think it would be a good jumping off point for a necessary refactor for node ESM/Unpkg's ?module mode/Vite/TS etc.

Issues that code addresses to some degree:

  1. removing require packages within the code
  2. Remove all module.export as a global hashmap use.
  3. Sharing globals as both runtime configuration and user-land API surface
  4. Reduce reliance on optional globals and use globalThis to check for them
  5. Reduced Node API surface area, including stderr.fd, writing to process.ENV, and other non JavaScript stuff.
  6. Avoid swallowing errors
  7. Avoid hoisting, use better structures like Class, singletons and modules instead
  8. Rename single word internal functions to multi-word names, specially when they conflict

I propose the following restructure:

  1. DebugCore.class.mjs (common.js)
  2. DebugFactory.class.mjs

Then for actual front facing code, we would use conditional exports to set the default entry point. You can do

{
  ".": {
    "node": "NodeDebug.class.mjs",
    "deno": "DenoDebug.class.mjs", 
    "browser": "BrowserDebug.class.mjs", // I think this is deprecated in favor of module
    "default": "Debug.class.mjs"
  }
}

Other things that would help:

  • Move away from Istanbul (deprecated) / Klarna, to the built-in new test runner for unit testing
  • We do not need a whole DOM browser for E2E... jsdom, might enough
  • Have way more sandboxes and examples for people to use this library... not just use it begrudgingly when they are stuck
  • Welcome experiments in some way... like a labs folder. ESM makes providing experimental exports, free to user-land.

Great api BTW!

@bryanjtc
Copy link

bryanjtc commented Nov 1, 2023

What is the status of v5? How long until a release that supports esm?

@Qix-
Copy link
Member Author

Qix- commented Nov 1, 2023

Debug already supports ESM, and we're still kind of blocked on some Node things.

@bryanjtc
Copy link

bryanjtc commented Nov 1, 2023

Debug already supports ESM, and we're still kind of blocked on some Node things.

When reading the readme I assumed it didn't supported it because of all the requires.
Have you thought of simplifying the release and push those blocking changes to v6?

@Qix-
Copy link
Member Author

Qix- commented Nov 1, 2023

There's not much to release at the moment. Plus it doesn't make sense to do much now until Node reaches feature parity with the requires() system.

Node ESM is inherently compatible with old require() packages by the way. Just because we have require() in the readme doesn't stop you from importing it.

@adominguezepiuse
Copy link

I hope all is well. I've been keeping an eye on the discussions regarding the ReDoS vulnerability. I was wondering if there's any general sense or rough estimate on when we might expect the release of version 5.x with the necessary security updates. I understand that these things take time, and I appreciate the team's efforts to ensure a thorough fix.

@Qix-
Copy link
Member Author

Qix- commented Dec 18, 2023

There's very little security risk in pre-5.x. Just don't feed user input into the main debug constructor.

@OleksandrKucherenko
Copy link

OleksandrKucherenko commented Dec 19, 2023

Will be great to have a conditional debug messages:

const showMessageToUser = /* some complex condition */
debug.if(showMessageToUser)(/* ... */)

Another great feature to have is a multiplexer, output of the same debug log-message to multiple namespaces:

debug.to('namespace1', ... , 'namespaceN')('something strange: %o', object)

this is useful when we have several namespaces that are attached to logs tracker systems (elk, datadog, etc) and we need that message be delivered to multiple "channels"

@OleksandrKucherenko
Copy link

OleksandrKucherenko commented Dec 19, 2023

One more feature: Escalate/DeEscalate

for example we have some complex logic that may raise the exception... so idea is: when we caught the exception escalate the logs verbosity and when for example we do not have exceptions for some defined time, automatically de-escalate verbosity.

try {
  /* some logic */

  debug.deescalate('2m', { /*options*/}) // normal execution, recover normal state of logs in 2 minutes
} catch (e) {
  /* that should never happens */

 // if it happens escalate verbosity for all namespaces for next 15mins
 debug.escalate('15m', {cause: e, namespaces: '*', /* options */}) 
}

and will be great to provide some kind of human readable time periods: 'now', '1m', '1h', '90m', '1h30m'

p.s. and it will be great to have some buffer of prev messages that were not published/printed, but in the moment of escalation they can be reviewed and published.

p.p.s. escalate/deescalate logic can be base on timer or "score" logic. "Score" logic means that we increase the priority score to some level, that corresponding specific levels of logs enabling (info, warning, debug, verbose, all). Escalate will increase the score, de-escalate will reduce the score.

ref: https://medium.com/@olku/logging-its-hard-to-make-it-right-part-1-caa066c0e6b

@Qix-
Copy link
Member Author

Qix- commented Dec 19, 2023

Both of those things are entirely out of scope for thie package, sorry.

@OleksandrKucherenko
Copy link

Can we have an debug lib extension API, so it will be possible to implement those features as additional library?

achingbrain added a commit to libp2p/js-libp2p that referenced this issue Aug 2, 2024
debug is a CJS module with CJS dependencies.

It will be an ESM module in it's [next major release](debug-js/debug#656),
however that release issue has been open for over five years so it
may never arrive.

This PR vendors in the debug module as typescript so we can move
on from CJS.
achingbrain added a commit to libp2p/js-libp2p that referenced this issue Aug 2, 2024
debug is a CJS module with CJS dependencies.

It will be an ESM module in it's [next major release](debug-js/debug#656), however that release issue has been open for over five years so when that will ship is anyone's guess.

weald is an API compatible port written in TypeScript and published as ESM.

We can revert this change if/when `debug` finally ships an ESM version.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion This issue is requesting comments and discussion help-wanted This issue has an actionable item
Development

No branches or pull requests

9 participants