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

Drop eventsource polyfill to let users opt in to streaming support #901

Open
wants to merge 17 commits into
base: master
Choose a base branch
from

Conversation

Shaptic
Copy link
Contributor

@Shaptic Shaptic commented Jan 3, 2024

What

This omits eventsource by default from the bundle so that users can opt in specifically if they want streaming support.

Why

This module is quite problematic in certain environments, and it unnecessarily limits the developer experience for those that do not care about streaming support (e.g. just not needing it, or being Soroban-only).

Testing

Confirmation would be deeply appreciated, as all I did was test with a basic example Node project:

mkdir test-streaming/
cd test-streaming/
yarn init -y
yarn add git+https://github.com/stellar/js-stellar-sdk.git#6378aae
cat > index.js <<END
const { Horizon } = require("@stellar/stellar-sdk")
const s = new Horizon.Server("https://horizon-testnet.stellar.org");
s.transactions().stream({
    onmessage: (record) => console.log(record),
    onerror: (data) => console.log(data)
});
END

Then, we can see the difference before and after installing eventsource:

$ node index.js
⚠️ No EventSource provider found: either polyfill it (e.g. `npm i eventsource`) or you will not have streaming support.
⚠️ The import error was: Error: Cannot find module 'eventsource'
⚠️ No EventSource provider found: there is no streaming support unless you polyfill it (e.g. `npm i eventsource`).
TypeError: EventSource is not a constructor
    at createEventSource (.../streaming-test/node_modules/@stellar/stellar-sdk/lib/horizon/call_builder.js:68:16)
    at TransactionCallBuilder.stream (.../streaming-test/node_modules/@stellar/stellar-sdk/lib/horizon/call_builder.js:118:7)
    at Object.<anonymous> (.../streaming-test/index.js:5:18)
    at Module._compile (node:internal/modules/cjs/loader:1256:14)
    ...

The third warning line is included in case the user does not have an onerror handler for their stream, to ensure that the error is regularly visible.

$ yarn add eventsource && node index.js
node index.js       
{
  _links: {
    self: {
      href: 'https://horizon-testnet.stellar.org/transactions/b9d0b2292c4e09e8eb22d036171491e87b8d2086bf8b265874c8d182cb9c9020'
    },
    ...

e.g. @aristidesstaffieri and @piyalbasu, could you check that this branch works in Freighter?

@Shaptic Shaptic added the dependencies Pull requests that update a dependency file label Jan 3, 2024
@Shaptic Shaptic self-assigned this Jan 3, 2024
Copy link

github-actions bot commented Jan 3, 2024

Size Change: -1.68 MB (-15%) 👏

Total Size: 9.76 MB

Filename Size Change
dist/stellar-sdk.js 5.47 MB -868 kB (-14%) 👏
dist/stellar-sdk.min.js 4.29 MB -809 kB (-16%) 👏

compressed-size-action

@piyalbasu
Copy link
Contributor

@Shaptic Thanks for flagging! I just installed this locally and ran through some smoke tests. Freighter builds and runs as expected 🎉

@Shaptic Shaptic linked an issue Jan 9, 2024 that may be closed by this pull request
@kalepail
Copy link
Contributor

kalepail commented Jan 31, 2024

Weekly reminder that merging this would make me a very happy man

My life is pain

This is the remedy

🎵

@kalepail
Copy link
Contributor

kalepail commented Jan 31, 2024

Also noting that I'd like to have this line considered for addition
https://github.com/kalepail/js-stellar-sdk/blob/make-eventsource-optional/package.json#L154
Essentially pinning the build tool for our included lockfile. Yarn 1 is very outdated and this can cause issues with automated CI/CD build tools like Cloudflare Pages which will try to use yarn 3

Copy link

socket-security bot commented Feb 10, 2024

🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎

To accept the risk, merge this PR and you will not be notified again.

Alert Package NoteSource
Native code npm/sodium-native@4.1.1
Filesystem access npm/envinfo@7.12.0

View full report↗︎

Next steps

What's wrong with native code?

Contains native code which could be a vector to obscure malicious code, and generally decrease the likelihood of reproducible or reliable installs.

Ensure that native code bindings are expected. Consumers may consider pure JS and functionally similar alternatives to avoid the challenges and risks associated with native code bindings.

What is filesystem access?

Accesses the file system, and could potentially read sensitive data.

If a package must read the file system, clarify what it will read and ensure it reads only what it claims to. If appropriate, packages can leave file system access to consumers and operate on data passed to it instead.

Take a deeper look at the dependency

Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev.

Remove the package

If you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency.

Mark a package as acceptable risk

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of ecosystem/package-name@version specifiers. e.g. @SocketSecurity ignore npm/foo@1.0.0 or ignore all packages with @SocketSecurity ignore-all

  • @SocketSecurity ignore npm/sodium-native@4.1.1
  • @SocketSecurity ignore npm/envinfo@7.12.0

@Shaptic
Copy link
Contributor Author

Shaptic commented Feb 10, 2024

It's a huge breaking change so I don't want to merge it just yet 😅 would rather have it alongside other big stuff

@Shaptic
Copy link
Contributor Author

Shaptic commented Feb 10, 2024

Yarn 1 is very outdated

If it ain't broke... upgrading to 3 seems like a pain in the ass for little benefit. But I've added the version lock as you requested!

@mollykarcher mollykarcher added this to the Sprint 44 milestone Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file
Projects
Status: Needs Review
Development

Successfully merging this pull request may close these issues.

Avoid importing eventsource when it isn't being used
4 participants