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

Winston does not work in browser #2196

Open
JakobJingleheimer opened this issue Sep 13, 2022 · 5 comments
Open

Winston does not work in browser #2196

JakobJingleheimer opened this issue Sep 13, 2022 · 5 comments

Comments

@JakobJingleheimer
Copy link

🔎 Search Terms

esbuild, isomorphic, universal

The problem

The root of the problem seems to stem from winston-transport, which require()s Node.js modules (ex util and os) even in the "browser" distribution. Also, the distribution is CJS, which is not runnable outside node.

Looking at the Winston dist, it appears to not be browser-friendly at all o.O Am I missing something?

What version of Winston presents the issue?

3.8.1

What version of Node are you using?

18.8.0

If this worked in a previous version of Winston, which was it?

No response

Minimum Working Example

No response

Additional information

No response

@wbt
Copy link
Contributor

wbt commented Sep 19, 2022

I agree it does not seem to be browser-friendly. I think this stems from origins in writing logs to files, which is a lot harder to do from the browser.

@GlenDC
Copy link

GlenDC commented Nov 2, 2022

I would like to pick up some contribution work to make winston more browser-friendly.

For a project of our own we discovered we can use https://github.com/defunctzombie/package-browser-field-spec to make out code different for browsers vs node, where needed.

Would this be an option you are willing to go for? It would mean that when using a package tool for browser usage, one no longer needs to shim the code itself, as we could from winston js simply make sure the browser-ready code is being used, allowing winston-js to be used as is.

What do you think?

@wbt
Copy link
Contributor

wbt commented Nov 4, 2022

I think the way to do this would likely involve splitting out the file transport more separately so the core doesn't rely on it and can be used independently.

@ryuujo1573
Copy link

This is interesting. Could anyone tell me if this is taken into consideration or todo stuffs?

@DABH
Copy link
Contributor

DABH commented Jun 13, 2023

Regarding splitting our the file transport, this is something on the todo list, but there isn't funding for the project right now to do more than maintenance, so we would likely need someone from the community to step up and take this on in order to get it implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants