There's also the option of using Jiti
It would add an extra dependency though
Show HN: Nub – A Bun-like all-in-one toolkit for Node.js
41–50 of 85 posts
Re: Show HN: Nub – A Bun-like all-in-one toolkit for Node.js
#42Respect for embracing existing tech instead of rewriting a worse version of it. Wonder where we would be today if all alternative-building effort went to Node instead (with proper leadership).
Fundamentally you can't fix a lot of things with this approach. Simple example: Node is the only serious OSS software I know of that has no way to document its config (in the config file itself). It's moronic! The Node people just adopted JSON without a thought, and then refused to consider any alternatives (even "JSON with comments"). When an organization digs into bad decisions, the only way to fix them is to start…
> Simple example: [package.json is JSON]
Why can't you fix this while embracing existing tech? I can imagine monkeypatching Node & NPM to add support for JSONC or JSON5 or whatever in the same way that Nub adds various features via monkeypatching. Is there some architectural reason that can't work?
You'd need `npm publish` to compile it down to plain JSON when publishing, but that seems like an okay compromise.
Re: Show HN: Nub – A Bun-like all-in-one toolkit for Node.js
#43Very smart. You can't lose all your customers for vibe-coding a migration to Rust if you are already written in Rust ;)
This project is already highly vibe-coded. Claude is the second contributor of the repo.
Re: Show HN: Nub – A Bun-like all-in-one toolkit for Node.js
#44Re: Show HN: Nub – A Bun-like all-in-one toolkit for Node.js
#45Very smart. You can't lose all your customers for vibe-coding a migration to Rust if you are already written in Rust ;)
Yea, not sure what “written in rust” adds to this. I would have thought that you could get the same functionality with a few shell scripts and a package.json.
Re: Show HN: Nub – A Bun-like all-in-one toolkit for Node.js
#46Respect for embracing existing tech instead of rewriting a worse version of it. Wonder where we would be today if all alternative-building effort went to Node instead (with proper leadership).
Fundamentally you can't fix a lot of things with this approach. Simple example: Node is the only serious OSS software I know of that has no way to document its config (in the config file itself). It's moronic! The Node people just adopted JSON without a thought, and then refused to consider any alternatives (even "JSON with comments"). When an organization digs into bad decisions, the only way to fix them is to start…
Isn't this a problem contained to npm more than Node itself?
I'm imagining pnpm or others being able to adopt a package.json file that allows comments, then, when actually publishing, ensuring the published package.json is regular JSON.
Re: Show HN: Nub – A Bun-like all-in-one toolkit for Node.js
#47Very smart. You can't lose all your customers for vibe-coding a migration to Rust if you are already written in Rust ;)
Yea, not sure what “written in rust” adds to this. I would have thought that you could get the same functionality with a few shell scripts and a package.json.
I assume speed.
But also, I know “rewrite in Rust” is a meme but if you’re doing something new, why not? I can’t see a good argument that a pile of shell scripts would be a superior way to organise things.
Re: Show HN: Nub – A Bun-like all-in-one toolkit for Node.js
#48Very cool idea which makes a lot of sense. Bun provides more (eg db drivers) but the DX is certainly a big part of its appeal.
For reference, the main author of Nub is Colin McDonnell who created Zod and even worked at Bun at some point.
Re: Show HN: Nub – A Bun-like all-in-one toolkit for Node.js
#49Very smart. You can't lose all your customers for vibe-coding a migration to Rust if you are already written in Rust ;)
There's a difference between running your app on a vibe coded runtime or just local DX tools though.
Re: Show HN: Nub – A Bun-like all-in-one toolkit for Node.js
#50Respect for embracing existing tech instead of rewriting a worse version of it. Wonder where we would be today if all alternative-building effort went to Node instead (with proper leadership).
Fundamentally you can't fix a lot of things with this approach. Simple example: Node is the only serious OSS software I know of that has no way to document its config (in the config file itself). It's moronic! The Node people just adopted JSON without a thought, and then refused to consider any alternatives (even "JSON with comments"). When an organization digs into bad decisions, the only way to fix them is to start…
I agree that it sucks not being able to have comments in package.json, but I think it's the right call to not adopt something like jsonc. It would break so much tooling at this point I don't think it would be worth it.