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

warning: Unused private constructor JsCache #34

Open
Guria opened this issue Nov 9, 2024 · 4 comments
Open

warning: Unused private constructor JsCache #34

Guria opened this issue Nov 9, 2024 · 4 comments

Comments

@Guria
Copy link
Contributor

Guria commented Nov 9, 2024

Currently Gleam reports JsCache type constructor is unused

warning: Unused private constructor
   ┌─ /home/aleksei_gurianov/oss/sketch/sketch/src/sketch.gleam:21:3
   │
21 │   JsCache(cache: style.Cache)
   │   ^^^^^^^^^^^^^^^^^^^^^^^^^^^ This private constructor is never used

Do you have any plans for it or is it just a leftover that could be safely removed?

@Guria
Copy link
Contributor Author

Guria commented Nov 9, 2024

Sorry, it is question to a gleam lang compiler since it depends on current target used.

@Guria Guria closed this as not planned Won't fix, can't repro, duplicate, stale Nov 9, 2024
@Guria
Copy link
Contributor Author

Guria commented Nov 9, 2024

@Guria Guria reopened this Nov 9, 2024
@ghivert
Copy link
Owner

ghivert commented Nov 11, 2024

If you take a look at the JS build, you'll see that constructor is used. It simply is unused on Erlang target. By default, when you're developing locally, the LSP will use the Erlang target, and as such, will display the warning.

At the moment, there's nothing much I can do, you can safely ignore the warning.

@Guria
Copy link
Contributor Author

Guria commented Nov 11, 2024

Yes, I understand the root cause of the issue. However, I believe this should still be addressed when a solution becomes technically feasible.
I've reopened this issue in the library repository since the Gleam core team indicated that this falls under the library author's responsibility.
As I mentioned in the linked ticket, having warnings that we need to "safely ignore" undermines the effectiveness of the warning system as a whole. I believe it's crucial to maintain clean compiler logs to preserve the value and purpose of warning messages. When developers become accustomed to ignoring certain warnings, they risk missing important issues that genuinely need attention.

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

No branches or pull requests

2 participants