Open Jarred-Sumner opened 2 years ago
how much time do you think this is gonna take?
how much time do you think this is gonna take?
It depends! @ohsnap4. It's very hard to predict when these priorities can get done in an open-source environment. Everyone is contributing in their spare time. But I think @Jarred-Sumner has a time-goal set up for this, the only thing we can do is to contribute meaningfully to this project.
As a user, I'd want:
2 > 3 since user experience > developer experience. 2 excites me most since it'll immediately speed up a lot of web apps. A good target should be to get Bun.js working with top 100 npm packages without changes to the packages themselves. This opens up an incremental adoption strategy for everyone to switch from node → bun and then optionally translate compat APIs for Node.js to even faster Bun.js equivalents if present.
I would love to help but feel like I'm to unexperienced yet, any pointers from a more experienced dev as to what to learn to be a little useful?
How high of a priority do you consider expanded documentation and community outreach to be?
I like to use bun in Termux but it didn't worked.
@Jarred-Sumner firstly great project 👍 love it.
Im wondering how I could help.
My first thoughts was to structure the documentation a bit more concisely, is that something that would be of interest + inline with priorities?
Feels like a wall of text at the moment, maybe as a starting point:
~/docs/*
) @halffunction
I like to use bun in Termux but it didn't worked.
Facing Same issue here!
Does Bun instead to expose all apis via the Bun
global like how it is currently, if so, it could get disorganized very quickly.
Crash issues:
Will process.stdin
and process.stdout
ever be implemented?
I guess they might be added for support with chalk
@Perodactyl There is a not a feature request regarding that so feel free to create it.
Chokidar is an extremely popular package that is core to other extremely popular packages. It currently does not work because fs.watch
is not implemented: https://github.com/oven-sh/bun/issues/832
Wow, I see so much work and progress going on here, I wish bun
the best. I believe it's going to be a breakthrough (if I'm not exaggerating) or at least game changer ^_^
Stability/SegFault improvement update -- #644 appears markedly improved from 1.3.0 -> 1.5.0
More notes in the issue. Incredibly impressive delta in such a short time.
Great work @Jarred-Sumner
SegmentationFault issues:
SegmentationFault at 0
when benchmarkinggraphql
#180SegmentationFault at 3
when parsing a large JSON file #188- SegmentationFault at 0 when adding entry to
[install.scopes]
inbunfig.toml
#190- SegmentationFault at 24 #216
- Dynamic import segfault #219
- SegmentationFault at 188 when running
bun add bun-framework-next
#220- BusError at 5100912640/SegmentationFault at 10 #242
bun install
error #410- Segmentation Fault after any async work reading headers #489
- Segmentation Fault #499
- Segmentation Fault while doing "bun install" in npm project #532
- Segmentation fault on a particular env variable with Apple Silicon #554
- Assigning process.env.NODE_ENV -> "SyntaxError: Left side of assignment is not a reference" #556
- bug: GC Seg Faults with Websockets Consumer #644
- Bun + Open Runtimes integration issue #684
- 0.1.4 upgrade fails on macOS Mojave #689
- Unable to run Next.js app with
bun dev
#723- bun a react-scripts -d get return SegmentationFault at 0 #791
- [ffi] Segmentation fault passing String buffer as char* #801
- Segmentation fault with EJS running under Mitata for benchmarking #811
- MINOR: Segmentation fault instead of useful error message when there are too many nested loops #817
- SegmentationFault at 26 when parsing json #826
- Segfault with built in modules + bun-utilities #840
- Crashing (SEGV) when using
JSON.stringify
#868- Segmentation Fault when installing packages #892
- SegmentationFault when using Honojs on Bun and testing using Hoppscotch. #915
Why not give them a label "segfault"?
I have done so, thanks for the advice.
node.js/polyfill issues:
I am totally agree with you in 4, I tried install bun but it fail coz my old cpu
I'd love to help, but don't want to jump in and duplicate work. Are there directly responsible individuals for these 4 items? Perhaps there's a team/squad working on these that I could get in touch with?
Key modules/features that I see missing from Node.js are:
fs.watch
required by Chokidardns
, tls
required by various network tools. I see above that net
is missing, but I haven't seen that in my testingchild_process
required by Commander which is a very popular framework for CLI applicationsHello, If you need more person involved, I guess you need to create cheat sheet for Zig because it's not popular language or example folder where you can add example about how to add a new Api also how to interact with deps that you choose and code style for better maintenance
Hello, If you need more person involved, I guess you need to create cheat sheet for Zig because it's not popular language or example folder where you can add example about how to add a new Api also how to interact with deps that you choose and code style for better maintenance
You can take a look https://github.com/oven-sh/bun/pull/1115
async_hooks
Node.js polyfill is also missing, required for Prisma.
async_hooks
is required for @sequelize/core@7
From https://nodejs.org/api/async_hooks.html:
Please migrate away from this API, if you can...We strongly discourage the use of the async_hooks API. Other APIs that can cover most of its use cases...
It looks like prisma uses only AsyncResource
, which is not deprecated based on this docs - https://nodejs.org/api/async_context.html#class-asyncresource
After #1266 fix, I cursorily tested these:
copySync
)During the process, I had some Integrity check failed
that required to call bun install
twice.
Apart from the fs-extra hiccup, it looks almost stable.
offtopic
After some digging it seems to be related to
lstatSync: { fn: "lstatSync", length: 1 },
i.e. the TODO means it doesn't support the options argument which has only one property (bigint
)
fixed
I like the project!
Can't wait to run my JS code in based Zig instead of cringe Rust.
Would really love to see some love for Koa as well and not just express as I happened across bun and would love to see if I can get it to work with https://github.com/strapi/strapi as I'm quite interested in the performance increases.
Who knows, maybe one day we would see Strapi rewritten in bun instead of Node :)
I have a big complicated Node.js Webpack project that I was skeptical would actually run in Bun. I had to nuke my node_modules and fix exactly 3 type errors to make it work. The "drop-in" replacement is not a lie, and for that you get a slow clap. :clap:
From nodejs.org/api/async_hooks.html:
Please migrate away from this API, if you can...We strongly discourage the use of the async_hooks API. Other APIs that can cover most of its use cases...
While I understand that Node itself recommends not using this API, I think it should be included in bun for compatibility reasons. Sequelize is one of (if not the) biggest JS ORMs so to have it not work in bun make all of my projects incompatible with the bun runtime
@xHyroM https://github.com/oven-sh/bun/issues/5288 should be added to https://github.com/oven-sh/bun/issues/798#issuecomment-1204775143
I would love to help but feel like I'm to unexperienced yet, any pointers from a more experienced dev as to what to learn to be a little useful?
One thing that is really helpful and can be pretty tedious to produce — but can be done without deep technical expertise — is to produce small test cases that reproduces bugs. See https://en.wikipedia.org/wiki/Minimal_reproducible_example. (For example: someone reports that "it crashes for this repo" -> "these 3 lines of code consistently reproduces the crash".)
I suggest considering implementing "dgram" from Node.js, since server application should be able to accept and send UDP packets, and not only TCP. Strangely no one yet mentioned it, but UDP is widely used for game servers.
When can support for VS Code step debugging be prioritized? Thanks
Any insight as to where Firestore sits on the priority queue?
I know that the amount of issues bun gets might be overwhelming but sometimes I feel like maintainers should read each issue at least once before deciding if an issue needs to be prioritized or not. This is because I sometimes feel like even if an issue is supposed to get priority based on the cases listed here, they often get ignored because the title might not refer to that specifically. But after reading the issue itself you realize that it needs to be addressed sooner.
There are way too many segfaults (on Windows atleast). Simply running some basic code (using the discord.js package, if that's related) ends up in a segfault. Seems like there's already an issue for my exact error (there's no message, just segfault at x address), but upon looking through the other issues, I can see a bunch of other segfaults
About the missing routemap tasks: CSS Parser, IIFE module export, etc, it would be nice to add a list with a prioritization order. It would help a lot to those of us who are developing libraries/frameworks based on Bun to know also the order in which things are going to arrive, even if it is approximate.
@Jarred-Sumner and the bun team you may find this useful for helping with organizing issues and the respective priorities, its a github app https://sweetjab.com/
Bun is a large project and it is early days. I think Bun needs to do a better job communicating what is a priority right now and what isn't.
Bun's top priorities:
bun install
should work as reliably as npm. We need more testing for error cases throughout Bun's test suite. We need to be running Address Sanitizer regularly and possibly Valgrind as well. We need to do fuzz testing.PRs that fit in the scope of top priorities will be reviewed ASAP. PRs that do not fit in this scope may take awhile to be reviewed