swc-node
loaders
Our great sponsors
swc-node | loaders | |
---|---|---|
6 | 2 | |
1,612 | 108 | |
2.2% | 0.0% | |
7.3 | 5.8 | |
19 days ago | about 1 month ago | |
TypeScript | ||
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
swc-node
-
Thoughts about Deno?
swc-node is much faster. No typechecking but you can have that running as a separate process with typescript in watch mode. Basically never have to wait for compiles or typechecking checking then.
-
Node + SWC make a lightning fast typescript runtime
fwiw swc has an official loader: https://github.com/swc-project/swc-node
- Node.js 18.x runtime now available in AWS Lambda
-
Next.js 12 - Rust Compiler, React 18 and Native ES Modules Support, React Server Components
I actually just switched my team's app over to use https://github.com/Brooooooklyn/swc-node for our Jest tests, but if we're going to upgrade to Next 12 it'd be nice to reuse whatever's included there.
-
Next.js 12
I actually upgraded my team's Jest config to use https://github.com/Brooooooklyn/swc-node a few weeks ago. However, our Jenkins CI agents run RHEL7, and neither of the Linux binary targets would run. The `x64-gnu` binary needed a `GLIBC_2_23` symbol when only 2.18 was available, and the `x64-musl` binary had no `musl-libc` on the machine. I don't own the Jenkins agents, so I couldn't install other deps myself.
I ended up building `musl-libc` from source on another RHEL7 agent, committed the `.so` to our repo, and added that to the `LD_LIBRARY_PATH` in our Jenkinsfile, and actually got that working.
I did see some mentions that Rust could build to target an older GLibc ( https://kobzol.github.io/rust/ci/2021/05/07/building-rust-bi... ), so I'm curious if Next is going to use copies of SWC built that way for better compat or if it will require more workarounds on my part.
I'm very curious if the Next SWC binaries
- Build Speed Improvements
loaders
-
Hagana - A novel approach to runtime protection for NodeJS to prevent supply chain attacks
In ESM environments, --require isn't sufficient. Loaders are still relatively new, but allow libraries to hook into node's import lifecycle. As mentioned previously testdouble uses this to shim ESM imports for stubs & mocks. You can use multiple loaders (currently via external libraries), with node's support for multiple --loader / --experimental-loader flags in the proposal stage.
- Next.js 12 - Rust Compiler, React 18 and Native ES Modules Support, React Server Components
What are some alternatives?
ts-node - TypeScript execution and REPL for node.js
vike - 🔨 Like Next.js / Nuxt but as do-one-thing-do-it-well Vite plugin.
sucrase - Super-fast alternative to Babel for when you can target modern JS runtimes
esbuild - An extremely fast bundler for the web
nextjs-tailwind-ionic-capacitor-starter - A starting point for building an iOS, Android, and Progressive Web App with Tailwind CSS, React w/ Next.js, Ionic Framework, and Capacitor
entr - Run arbitrary commands when files change
Next.js - The React Framework
next-rsc-demo - Demo repository for Next.js + React Server Components [Moved to: https://github.com/vercel/next-react-server-components]
awayto - Awayto is a curated development platform, producing great value with minimal investment. With all the ways there are to reach a solution, it's important to understand the landscape of tools to use.
loader - Loader Standard
faunadb-js - Javascript driver for FaunaDB v4