Adds console disclaimer when running direct sql from the browser

[lneves12]

Config example for websocket:

                neonConfig.disableWarningBrowser = false;
                const pool = new Pool({ connectionString });

                const sql = neon(connectionString, {
                  disableWarningBrowser: true
                });

I guess for now this should be enough, we can document it later if needed. This way is a good way to get some signal if there are a lot of people disabling it

[lneves12]

this was mainly to avoid adding dom types globally to the tsconfig. It makes it more type safe

[jawj]

(1) Looks like this applies only to HTTP queries. I guess that's because those are the only ones we support auth for? But it's also possible to connect from a browser via WebSockets. Have we considered warning about that too?

(2) We should probably provide a way to suppress this message being printed, so that users can opt out of us cluttering up their console (and maybe making them look a little unprofessional in production).

[davidgomes]

(1) Looks like this applies only to HTTP queries. I guess that's because those are the only ones we support auth for? But it's also possible to connect from a browser via WebSockets. Have we considered warning about that too?

(2) We should probably provide a way to suppress this message being printed, so that users can opt out of us cluttering up their console (and maybe making them look a little unprofessional in production).

(1) I agree we should do WS as well.

(2) I wouldn't do this, I think the point is for it to shock people. If someone really pressures us into doing this we can consider it later, shouldn't be hard.

[lneves12]

1. agreed as well. I added the warning to websocket as well. (I haven't tested the websocket part, but I will later, it should just work)

2. I don't have a strong opinion about this one. It might be a bit annoying since it is printed in every execution, but I guess that's the goal.

[jawj]

It might be a bit annoying since it is printed in every execution

Yeah: I see your point, @davidgomes, but I do think I'd want a way to opt out. Maybe a neonConfig option? Note that one place this warning will appear otherwise is in the console for our own SQL Editor!

One other comment: out of an abundance of caution, perhaps we should also test for typeof console !== 'undefined' && typeof console.log !== 'undefined' before logging?

[davidgomes]

It might be a bit annoying since it is printed in every execution

Yeah: I see your point, @davidgomes, but I do think I'd want a way to opt out. Maybe a neonConfig option? Note that one place this warning will appear otherwise is in the console for our own SQL Editor!

I don't think we should a config option until someone asks for it. I'd rather avoid adding surface area and complexity unless someone specifically complains about it. More configs means more docs, more tests, and more surface area to maintain.

One other comment: out of an abundance of caution, perhaps we should also test for typeof console !== 'undefined' && typeof console.log !== 'undefined' before logging?

Good idea!

[lneves12]

If the warning appears in our SQL editor that's a bit concerning, so I tend to agree that having a way to disable would make sense. This warning doesn't apply to that use case

[davidgomes]

Ah I see I forgot about that use case. Yeah let’s add a config then!

…

On Wed, 23 Apr 2025 at 23:51, Luis Neves ***@***.***> wrote: *lneves12* left a comment (neondatabase/serverless#158) <#158 (comment)> If the warning appears in our SQL editor that's a bit concerning, so I tend to agree that having a way to disable would make sense. This warning doesn't apply to that use case — Reply to this email directly, view it on GitHub <#158 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFVB5NQ2NSYCSLSBCEWS3323ADPLAVCNFSM6AAAAAB3WAIOG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMRVGU3TMMJVHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jawj]

Sorry, just two more suggestions:

1. We don't know that people are using RLS, right? So While your database is protected by Row-Level Security (RLS) ... should perhaps be Even if your database is protected by Row-Level Security (RLS) ....
2. I think disableBrowserWarning or disableWarningInBrowsers would sound a lot more natural to me than disableWarningBrowser.

[davidgomes]

Sorry, just two more suggestions:

1. We don't know that people are using RLS, right? So While your database is protected by Row-Level Security (RLS) ... should perhaps be Even if your database is protected by Row-Level Security (RLS) ....
2. I think disableBrowserWarning or disableWarningInBrowsers would sound a lot more natural to me than disableWarningBrowser.

Agreed on both points!

[lneves12]

Sorry, just two more suggestions:

1. We don't know that people are using RLS, right? So While your database is protected by Row-Level Security (RLS) ... should perhaps be Even if your database is protected by Row-Level Security (RLS) ....
2. I think disableBrowserWarning or disableWarningInBrowsers would sound a lot more natural to me than disableWarningBrowser.

agreed, good feedback. Already updated it

[jawj]

If the option is not specified here, do we inherit from the global configuration parameter? I think we probably should.

[lneves12]

I guess it makes sense. The implementation is a bit weird, because neonConfig in reality is a socket config that we don't use for the http client, but I guess this is good enough (already updated)

[jawj]

LGTM!