## 1. Project Overview & Quickstart (parcel-bundler/app.c9a6fe.js) # app.c9a6fe.js Open-source repository parcel-bundler/app.c9a6fe.js ### Repository Details - **Repository:** [parcel-bundler/app.c9a6fe.js](https://github.com/parcel-bundler/app.c9a6fe.js) - **Primary Language:** Code *Note: High-volume repository documentation is actively indexed and synchronized by YakaAI.* ## 2. Official Technical Reference & Guides (parcel-bundler/website) ## File: README.md # 🌎 Parcel 2 website This is the website for Parcel v2. Please help us out by giving your feedback in issues, and feel free to send pull requests for contributions. 😍 ## Contributing Start a local server using: ```bash yarn yarn serve ``` The website is automatically deployed using [Vercel](https://vercel.com). Search is powered by [Algolia DocSearch](https://docsearch.algolia.com/). --- ## File: package.json { "name": "parcel-website", "version": "0.0.0", "private": true, "license": "MIT", "workspaces": [ "packages/*" ], "browserslist": [ "last 2 Safari versions", "last 2 Chrome versions", "last 2 Firefox versions" ], "scripts": { "build": "rm -rf _site dist; eleventy; parcel build src/home/index.html '_site/*.html' _site/*/index.html '_site/*/*/*.html' --public-url $(node public-url.js)", "watch": "eleventy --watch", "serve": "parcel src/home/index.html '_site/*.html' _site/*/index.html '_site/*/*/*.html'", "start": "run-p watch serve", "debug": "DEBUG=* eleventy", "lint": "prettier --write 'generate-api-docs/*.js' 'src/**/*.{js,json,md,scss}'", "generate-api-docs": "node generate-api-docs/ ../ ./api", "generate-api-docs:watch": "nodemon -w ../parcel -w generate-api-docs -x yarn generate-api-docs" }, "devDependencies": { "@11ty/eleventy": "^1.0.2", "@11ty/eleventy-navigation": "^0.3.5", "@11ty/eleventy-plugin-rss": "^1.2.0", "@11ty/eleventy-plugin-syntaxhighlight": "^4.1.0", "@babel/generator": "^7.20.1", "@babel/parser": "^7.20.1", "@babel/traverse": "^7.20.1", "@parcel/packager-xml": "^2.15.0", "@parcel/transformer-js": "^2.15.0", "@parcel/transformer-react-refresh-wrap": "^2.15.0", "@parcel/transformer-sass": "^2.15.0", "@parcel/transformer-xml": "^2.15.0", "eleventy-plugin-toc": "^1.1.0", "flow-bin": "^0.177.0", "husky": "^4.3.6", "lint-staged": "^10.5.3", "markdown-it": "^12.0.4", "markdown-it-anchor": "^8.0.1", "nodemon": "^2.0.6", "npm-run-all": "^4.1.5", "nullthrows": "^1.1.1", "parcel": "^2.15.0", "postcss": "^8.3.6", "posthtml-include": "^1.7.0", "posthtml-prism": "^1.0.4", "prettier": "2.7.1", "process": "^0.11.10", "sass": "^1.55.0", "sharp": "^0.33.5", "tailwindcss": "^3.2.1", "tailwindcss-safe-area": "^0.2.2" }, "dependencies": { "@alpinejs/intersect": "^3.10.5", "alpinejs": "^3.10.5", "focus-visible": "^5.2.0", "marked": "^2.0.7", "react": "^17.0.2", "react-dom": "^17.0.2", "react-use": "^17.3.1" }, "resolutions": { "gulp-sass": "5.0.0", "sass": "1.55.0" }, "lint-staged": { "*.{md,scss,js,json}": "prettier --write" }, "husky": { "hooks": { "pre-commit": "lint-staged" } }, "alias": { "./assets/**": "./src/assets/$1", "./plugin-browser/**": "./src/plugin-browser/$1" }, "@parcel/transformer-css": { "pseudoClasses": { "focusVisible": "focus-visible" } } } --- ## File: vercel.json { "version": 2, "alias": ["parceljs.org"] } --- ## File: .yarnrc.yml nodeLinker: node-modules yarnPath: .yarn/releases/yarn-3.2.4.cjs --- ## File: packages/parcel-namer-website/package.json { "name": "parcel-namer-website", "version": "1.0.0", "main": "WebsiteNamer.js", "engines": { "parcel": "^2.0.0-beta.1" }, "dependencies": { "@parcel/plugin": "^2.15.0" } } --- ## File: packages/parcel-resolver-website/package.json { "name": "parcel-resolver-website", "version": "1.0.0", "main": "WebsiteResolver.js", "engines": { "parcel": "^2.0.0-beta.1" }, "dependencies": { "@parcel/plugin": "^2.15.0" } } --- ## File: src/src.json { "tagOrder": [ "Getting Started", "Migration", "Features", "Recipes", "Languages", "Plugin System" ] } --- ## File: src/blog/blog.json { "tags": "Blog" } --- ## File: src/blog/alpha1/alpha1.md --- layout: layout.njk eleventyNavigation: key: blog-alpha-1 title: Parcel 2 alpha 1 is here! date: 2019-09-13 summary: Parcel 2.0.0-alpha.1 is here! --- Today I’m incredibly excited to release the first alpha version of Parcel 2! Please try it out and help us take Parcel 2 to the finish line. Check it out on GitHub! Parcel 2 is a ground up rewrite of Parcel that we’ve been working on for over a year, and designing for almost a year before that. It incorporates everything we’ve learned building Parcel since the beginning, and the result is more **extensible**, **scalable**, and **reliable** than Parcel 1, while retaining the ease of use and **developer experience** you’ve come to expect from Parcel. - **🎛 Extensibility** — Parcel 2 is fully extensible, from end to end. The plugin types have been expanded to allow extending and overriding nearly all of the core behavior with easy to configure pipelines. While the default settings include everything in Parcel 1 (and more), now **you can customize and extend just about everything** if you need to. - **⚖️ Scalability** — While Parcel has always utilized parallelism and caching to scale to large applications, this is taken even further in Parcel 2. We now **cache and parallelize even more** of Parcel’s work, so you can expect even faster builds, especially cached builds. We also keep much less in memory, so Parcel 2 can scale to even larger apps. - **💪 Reliability** — Parcel 2 improves the reliability of our cache while at the same time improving performance to the max. We utilize a brand new cross platform filesystem [watcher](https://github.com/parcel-bundler/watcher), which can detect granular file changes even while Parcel is not running. At the same time, our asset graph can be invalidated super granularly, which means that **cached builds have almost exactly the same performance as watch mode!** ### Configuration Parcel famously requires zero configuration. This never meant non-configurable, just that Parcel attempted to infer as much as possible from the code itself, and used existing config files for other tools (e.g. .babelrc). Users have loved the ease of use and developer experience that this has provided, but there are always edge cases and real use cases that require a bit more customizability. Parcel 2 is **optionally configurable**. The default config built into the Parcel 2 CLI will be enough for the majority of apps and includes everything Parcel 1 supported and more, but Parcel 2 supports extending the core with additional functionality through a complete set of plugin types designed specifically for each of Parcel’s core stages. - **🔎 Resolvers** — resolvers turn imports like import './foo' or import 'react' into full file paths like /my/project/foo.js. The default resolver in Parcel 2 includes support for the node resolution algorithm, plus some extras like aliases. But, if you want to extend or override the resolution algorithm for your project, now you can with a resolver plugin. - **🦋 Transformers** — transformers compile code and other assets from one language to another, or just transform files in some way. For example, the TypeScript transformer compiles TypeScript to JavaScript, and the Babel transformer transpiles JavaScript to different JavaScript. Transformers are also responsible for extracting dependencies from code, such as import statements and require calls, which get passed back to the resolver, to another transformer, and so on until a full asset graph for the application is built. - **🗃 Bundlers** — bundler plugins take an asset graph as input, and output a bundle graph which is like the asset graph but with the assets grouped into bundles. The default bundler groups assets with like file types like JavaScript and CSS together, and performs code splitting and some additional optimizations. I’m excited to see how the community will experiment with custom bundler plugins that take advanced code splitting even further! - **🏷 Namers** — namer plugins are responsible for determining the output filenames for each bundle. The default namer plugin includes content hashing for long term cachability of assets, and the same naming rules as Parcel 1. If you need to customize the filenames of your bundles for any purpose, a namer plugin is the way to do it! - **👟 Runtimes** — runtime plugins allow inserting code into bundles at build time. By default, we use this to add the runtime code needed to load bundles asynchronously, and insert the hot module replacement runtime for development, but you could use them to insert any kind of code you need conditionally at build time. - **📦 Packagers** — packagers combine assets of a common type into an output bundle that can be loaded in a browser. For example, the JS packager combines JavaScript files together so that they are executed in the right order, at the right time. - 🗜 **Optimizers** — optimizer plugins optimize a bundle in some way, for example minimizing or compressing files. For example, the [terser](https://github.com/terser-js/terser) optimizer minimizes JavaScript bundles. - **✅ Validators** — validator plugins run in the background to perform code validation, such as linting (e.g. eslint) or type checking (e.g. TypeScript). They don’t block development builds, but when enabled, will block production builds from succeeding. Since they run in the background on a low priority queue, they don’t cause any performance degradation when you just want to make changes quickly. - **🗞 Reporters** — reporter plugins receive events throughout the bundling process with status information and logging events. For example, the Parcel 2 CLI is implemented with a reporter, as is the dev server. You could also use reporters to implement other types of UIs or dashboards, bundle visualizers, etc. All of these are configured in a very simple JSON file called .parcelrc. There is no JavaScript or complex logic required to configure Parcel, if you ever need to at all. You can also extend other configs, and share them as npm packages. We expect that most configs will extend the @parcel/config-default package to add or override some of the built-in defaults as needed. For example, here’s how you’d add a transform for [Dart](https://dart.dev) to your app once you’ve published the parcel-transform-dart package. { "extends": ["[@parcel/config-default](http://twitter.com/parcel/config-default)"], "transforms": { "*.dart": ["parcel-transform-dart"], } } ### Small Core Now that everything in Parcel is split out into plugins, Parcel core is incredibly small. It now essentially just runs other tools as needed based on a graph of the files in your application, in a very intentional and optimized way. Everything is designed to be done in parallel and be cacheable, both locally and eventually, across machines. Parcel maintains a highly optimized graph of your entire application, which can be invalidated super granularly to trigger rebuilds of only exactly what is needed when things change. This includes both your code, and everything that influences how that code is built, such as config files (e.g. .babelrc), plugin versions, and more. The whole graph is cached on disk when Parcel stops, and can be restored on startup and invalidated granularly so that only files that changed are rebuilt. It’s just like watch mode, but even when Parcel is restarted! _A Parcel asset graph, showing a build with multiple targets (see below)._ The worker farm has been updated to make use of the new [worker_threads](https://nodejs.org/api/worker_threads.html) module built into Node 12 when available, which has lower overhead than the multi-process backend used in previous versions. Additionally, we’ve abstracted all filesystem access in Parcel so that it is pluggable with different filesystem implementations. For example, you might want to use an in memory filesystem to run Parcel in the browser. ### Multiple targets, and bundle splitting Aside from a completely new core and plugin system, Parcel 2 also has a bunch of new features, including support for **multiple targets**, and **bundle splitting**. Parcel 2 allows you to configure builds for **multiple targets**, which will be built in parallel. For example, you may want to build a version of your application for modern browsers with modern syntax, and one for legacy browsers with more transpilation. Or maybe you want to build a library for both node and the browser. Now you can do that and more, by configuring targets in your package.json. The following example will result in two complete builds, compiled for a recent Chrome version, and more legacy browsers. These can then be loaded with differential loading techniques to decrease bundle sizes for modern browsers. { "browser": "dist/legacy/index.js", "browserModern": "dist/modern/index.js", "targets": { "browserModern": { "engines": { "browsers": [ "last 1 Chrome version" ] } }, "browser": { "engines": { "browsers": [ "> 0.25%" ] } } } } In local development, we avoid this extra work by compiling for a default modern browser target, for performance. This means that Babel and other tools need to do less work to transpile your code, when you’re just testing in Chrome. If you need to test a specific target (e.g. an old browser like IE 11), you can choose to build for that target with the --target option to the CLI. Parcel 2 also supports advanced **bundle optimizations**, which automatically split out common dependencies like react and other libraries into their own bundles that can be loaded in parallel and cached separately from the rest of your code. This should result in smaller initial bundle sizes than Parcel 1, because it no longer hoists common dependencies to the top of the tree when they aren’t needed by the entry bundle. ### Whole application bundling From the beginning, Parcel went farther than many other tools in bundling your whole application, including JavaScript, CSS, HTML, and static assets. Most other bundlers are still very JavaScript focused, and convert all asset types to JS, possibly with additional plugins to extract them again later. Parcel is file type agnostic, and Parcel 2 takes this even further by allowing you to override and compose every aspect how your code is processed. Parcel 2 plugins are organized into pipelines, which can be composed very easily to specify advanced transformations and build steps. Assets match an initial pipeline by a glob, and run through all of the plugins in that pipeline until the file type changes (e.g. .ts → .js). Then, they continue through the next pipeline, and so on until the end of a pipeline is reached. This allows individual plugins to focus on a single task, and lets the user compose multiple plugins together to do something more complex. Transformations can also output multiple assets, in case there are inline assets of a different type, such as an inline ` ``` becomes: ```html ``` This happens automatically based on your browser targets, as declared in the `"browserslist"` key in your package.json file. If some of your targets don't support ES modules natively, a `nomodule` version will be compiled automatically. ## Improved JSX support Parcel has always supported JSX out of the box, and even automatically detects which library you're using (e.g. React, Preact, etc.) and compiles accordingly. New in this release, Parcel now supports the [new JSX runtime](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html) added in React 17. This is completely automatic – Parcel detects the version of React used by your code and chooses the correct JSX runtime accordingly. The new JSX runtime should result in smaller bundles, and performance improvements. You also no longer need to import React manually in every file in order to use JSX. Please read the [blog post](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html) from the React team for more information. In addition, Parcel will now read the `tsconfig.json` or `jsconfig.json` file in your project, which allows you to configure several aspects of JSX compilation. You can use this to override the JSX runtime, library, and other properties, as well as enable other experimental JavaScript features like decorators. Please see the [TSConfig reference](https://www.typescriptlang.org/tsconfig) from the TypeScript team for more information. ## Improved worker support Parcel has supported web workers and service workers for a long time, and in this release we’ve made some major improvements. Similar to ` ``` See [the documentation](/features/dependency-resolution/#url-schemes) for more info about the URL schemes supported by Parcel. ## Thanks Parcel 2 has been a long process, and would not have happened without the work of the amazing core team, and all of the [contributors](https://github.com/parcel-bundler/parcel/graphs/contributors) who have been involved over the years. And thanks to everyone who has sponsored or donated on [Open Collective](https://opencollective.com/parcel) for helping us recognize their hard work. Current: - [Will Binns-Smith](https://twitter.com/wbinnssmith) - [Jasper De Moor](https://twitter.com/JasperDeMoor) - [Brian Do](https://github.com/thebriando) - [Eric Eldredge](https://twitter.com/lettertwo) - [Agnieszka Gawrys](https://github.com/AGawrys) - [Devon Govett](https://twitter.com/devongovett) - [Gora Kong](https://twitter.com/gorakong) - [Niklas Mischkulnig](https://twitter.com/mischnic) Alumni: - [Jamie Kyle](http://twitter.com/buildsghost) - [Joey Slater](https://twitter.com/TheJoeySlater) - [Maia Teegarden](https://twitter.com/padmaia) - [Kyle Welch](https://twitter.com/kylewelch) ## Try it out! Though we’ve been working on it for a long time, Parcel 2 is really just getting started. We’re excited to see how you use it, and have many more features and improvements coming soon. Stay tuned! - [GitHub](https://github.com/parcel-bundler/parcel) - [Discord community](https://discord.gg/XSCzqGRuvr) - [Support us on Open Collective](https://opencollective.com/parcel) --- ## File: src/blog/v2-12-0/v2-12-0.md --- layout: layout.njk title: Parcel v2.12.0 eleventyNavigation: key: blog-parcel-2-12-0 title: Parcel v2.12.0 date: 2024-02-28 --- Parcel v2.12.0 introduces support for macros, which enable you to generate code at build time using regular JavaScript functions. It also includes a new online REPL, improves our CSS bundling support, adds configuration options to fine tune your app's code splitting, and improves performance and memory usage. ## Macros Parcel v2.12.0 introduces support for [macros](/features/macros/). Originally implemented in [Bun](https://bun.sh/docs/bundler/macros), Macros are JavaScript functions that run at build time instead of being bundled. The value returned by a macro is inlined into the bundle in place of the original function call. This allows you to generate constants, code, and even additional assets without any custom plugins. Macros are imported using an [import attribute](https://github.com/tc39/proposal-import-attributes) to indicate that they should run at build time rather than being bundled into the output. You can import any JavaScript or TypeScript module as a macro, including built-in Node modules and packages from npm. This example uses the [regexgen](https://github.com/devongovett/regexgen) library to generate an optimized regular expression from a set of strings at build time. ```ts import regexgen from 'regexgen' with {type: 'macro'}; const regex = regexgen(['foobar', 'foobaz', 'foozap', 'fooza']); console.log(regex); ``` This compiles to the following bundle: ```js console.log(/foo(?:zap?|ba[rz])/); ``` As you can see, the `regexgen` library has been completely compiled away, and we are left with a static regular expression! Parcel's implementation of macros also enables you to generate functions at build time, and even emit new assets. For example, macros can generate CSS which will be statically extracted into a CSS bundle as if it was imported from the JS file. This example accepts a string of CSS and returns a generated class name. The CSS is added as an asset and bundled into a CSS file, and the JavaScript bundle only includes the generated class name as a static string. {% sample %} {% samplefile "index.ts" %} ```tsx import {css} from './css.ts' with {type: 'macro'};
Hello!
``` {% endsamplefile %} {% samplefile "css.ts" %} ```ts import type {MacroContext} from '@parcel/macros'; export async function css(this: MacroContext | void, code: string) { let className = hash(code); code = `.${className} { ${code} }`; this?.addAsset({ type: 'css', content: code }); return className; } ``` {% endsamplefile %} {% endsample %} The bundled output of the above example would look like this: {% sample %} {% samplefile "index.js" %} ```tsx
Hello!
``` {% endsamplefile %} {% samplefile "index.css" %} ```css .ax63jk4 { color: red; &:hover { color: green; } } ``` {% endsamplefile %} {% endsample %} This is basically a CSS-in-JS library with build-time static extraction in just a few lines of code! And since macros are just regular JavaScript or TypeScript functions, you can create any API on top of this that you want, for example generating CSS using an object API or theme values. We are excited to see what innovations this unlocks – for CSS-in-JS and much more. Check out [the documentation](/features/macros/) to learn more. ## REPL Parcel now has a [REPL](https://repl.parceljs.org/) where you can try it out right in your browser! [Niklas Mischkulnig](https://github.com/mischnic) has been working on the REPL over the course of several years, and we're excited that it's finally integrated into our website. The REPL features a full code editor, file browser, and support for most Parcel features including watch mode, dev server, hot module replacement, and more. Under the hood, the REPL is powered by cutting edge web technologies including Web Assembly, service workers to host the dev server, a web worker backend for multi-core processing, and IndexedDB for package manager caching. It can even install packages from npm by running a compiled version of Yarn for the browser. The REPL is great for playing around with Parcel and seeing how things are compiled. It's also great for creating shareable bug reproductions. [Check it out](https://repl.parceljs.org/)! ## Lightning CSS powered bundling Parcel has used [Lightning CSS](https://lightningcss.dev) to transform CSS files by default for a while. Now Parcel uses it for bundling CSS files as well. This brings support for modern CSS features like `@import` with [cascade layers](https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/Cascade_layers), improved support for importing with media and supports queries, and more correct handling of complex CSS ordering issues. ## Manual shared bundles By default, Parcel automatically code splits your code for maximum cache efficiency. Common modules that are shared between multiple parts of your application are extracted into a [shared bundle](/features/code-splitting/#shared-bundles) so that they can be loaded and cached separately by the browser. But sometimes, you might know more than Parcel about how a certain part of your app should be loaded, choosing to over-fetch up front in order to optimize later. In this release, we're introducing support for manual shared bundles to address this. Manual shared bundles let you configure Parcel to ensure that certain modules are always bundled together no matter where they are used. For example, you could create a vendor bundle that loads a set of commonly used libraries, or group together the assets for a specific route into a single bundle. This is specified using globs to match against file paths, as well as additional options to group by root asset or type, split into multiple parallel http requests, and more. Check out [the documentation](/features/code-splitting/#manual-shared-bundles) for all the details. Manual shared bundles are best applied after trying Parcel's default bundling algorithm and doing real-world performance testing. When you have a specific performance issue that can't be solved by changing your code structure, use manual shared bundles to override Parcel's default behavior. Manual shared bundles can also be useful when porting code from other bundlers like webpack. ## Performance improvements Like most Parcel releases, v2.12.0 also includes some performance improvements. In this release, we've improved our core graph data structure to reduce memory usage by ~52%, and improve performance of writes by ~5%. For a real world, very large app, this amounts to an ~800MB reduction in memory usage with no regression in startup, build, or shutdown times! If you're interested in learning how we made these optimizations, check out [the PR](https://github.com/parcel-bundler/parcel/pull/9444). And for more background on our custom graph data structure backed by SharedArrayBuffer, we now have some [documentation](https://github.com/parcel-bundler/parcel/blob/v2/docs/AdjacencyList.md). Also in this release, we've improved the way Parcel stores the graph to disk to work in small chunks during idle time in development rather than blocking the process from shutting down while the graph is being serialized. Instead of serializing the entire graph at once, we now track which parts have been modified and only re-serialize those. This should improve the perceived shut down performance of Parcel for very large projects. ## Thanks! Thanks to everyone who contributed to this release! Check out the [full changelog](https://github.com/parcel-bundler/parcel/releases/tag/v2.12.0) for all of the other bug fixes and improvements. - [GitHub](https://github.com/parcel-bundler/parcel) - [Discord community](https://discord.gg/XSCzqGRuvr) - [Support us on Open Collective](https://opencollective.com/parcel) --- ## File: src/blog/v2-14-0/v2-14-0.md --- layout: layout.njk title: Parcel v2.14.0 eleventyNavigation: key: blog-parcel-2-14-0 title: Parcel v2.14.0 date: 2025-03-18 --- Parcel v2.14.0 introduces beta support for React Server Components, which can be integrated into existing client-rendered apps, server rendered at request time, or statically rendered to HTML at build time. In addition, it adds first-class MDX support, a CLI to scaffold new Parcel apps, and a new React error overlay. It also optimizes browser caching with native HTML import maps. This is a big release, so let's dive in! ## React Server Components Parcel v2.14.0 introduces beta support for [React Server Components](/recipes/rsc/), a new type of component that renders ahead of time, on the server or at build time. Server Components seamlessly integrate client and server code in one unified component tree, helping reduce client bundle sizes by pre-rendering non-interactive components. Unlike other RSC implementations, Parcel is not a full framework. Instead, it provides the tools you need to build your own application or framework from scratch with much less work. This gives you freedom to experiment with new patterns, or integrate Server Components into an existing app without a major rewrite. Thanks to its existing multi-environment support, Parcel integrates server and client code in one unified module graph, building your entire app in a single command and supporting features like code splitting across environments. This includes support for the ["use client"](https://react.dev/reference/rsc/use-client) and ["use server"](https://react.dev/reference/rsc/use-server) directives to declare environment boundaries, dynamic import to load components on demand based on data, and more. Check out our [rsc-examples](https://github.com/parcel-bundler/rsc-examples) repo for complete example apps built with React Server Components and Parcel, and see [the documentation](/recipes/rsc/) for a deep dive. ### Integrating into a client-rendered app Parcel enables incremental adoption of Server Components within existing client-rendered React apps. For example, instead of returning JSON from an API server for a new feature, you could render Server Components. This can help reduce client bundle sizes by sending only the components needed to render the requested data, and omitting heavy non-interactive components (e.g. Markdown renderers) from the client bundle entirely. ```jsx import express from 'express'; import {renderRSC} from '@parcel/rsc/node'; let app = express(); app.get('/comments', (req, res) => { renderRSC().pipe(res); }); async function Comments() { // Load data from a database... let comments = await db.getComments(); // Render Markdown and interactive Client Components return comments.map(comment => (

Posted by: {comment.user}

)); } ``` On the client, Server Components can be loaded using [React Suspense](https://react.dev/reference/react/Suspense). ```jsx import {fetchRSC} from '@parcel/rsc/client'; function App() { return ( Loading comments...}> ); } let request; function Comments() { request ??= fetchRSC('http://localhost:3000/comments'); return request; } ``` Server Components can be integrated into an existing client-rendered SPA without rewriting your whole app. Simply add a new target pointing at your server code, alongside your existing SPA. Parcel will build both targets together, and share common dependencies between them. Check out [the docs](/recipes/rsc/) to learn more. ### Server rendering In a client-rendered React app, the entry point for your Parcel build is typically an HTML file. The output of the build might be uploaded to a static file server or CDN. After the HTML and JavaScript loads, you might request data from an API server and render it with components on the client. In the process of rendering the data, you might dynamically load additional components or data. This is a performance problem called a _network waterfall_. HTML JavaScript CSS Data Data JavaScript React Server Components can optimize network waterfalls by rendering to HTML as part of the initial request. This avoids additional API requests to load data, and allows components needed to render the data to be loaded in parallel instead of in series. HTML + Data JavaScript CSS JavaScript When using server rendering, the entry point for your Parcel build is the source code for your server instead of a static HTML file. Parcel v2.14.0 includes out of the box support for running Node servers in development mode. Running `parcel src/server.js` will build your server, and run it with built-in hot reloading when you make changes just like your client side code. Check out [the docs](/recipes/rsc/#server-rendering) for more information. ### Static rendering Parcel also supports pre-rendering React Server Components to fully static HTML at build time. For example, a marketing page or blog post is often static, and does not contain dynamic data personalized for the user. Pre-rendering allows these pages to be served directly from a CDN rather than requiring a server. Parcel now includes a built-in static site generator powered by React Server Components out of the box. Entry components are rendered to static HTML at build time, with interactive Client Components hydrated in the browser. Parcel provides a list of all pages along with metadata about the current page to each entry component, allowing it to render site navigation. With [MDX](/recipes/rsc/#mdx), it also generates a table of contents for each page, and provides static exports as metadata. See below for more on MDX. ```jsx export default function Page({pages, currentPage}) { return ( {currentPage.name} ); } ``` You can also mix static and dynamic pages in the same app by creating multiple targets. For example, a marketing page could be statically rendered and deployed to a CDN, and your product's dashboard could be server rendered. See [the docs](/recipes/rsc/#static-rendering) for more details. ## First-class MDX support Parcel now includes [first-class MDX support](/languages/mdx/) out of the box. It is written in Rust for performance using [mdx-rs](https://github.com/wooorm/mdxjs-rs), and deeply integrated with Parcel. Dependencies such as images and links in both Markdown and JSX syntax are detected and processed by Parcel, just like HTML. Custom code block components can be provided to easily implement syntax highlighting and inline rendered examples, perfect for documentation sites. MDX can also be used together with React Server Components, with an automatically extracted table of contents and metadata from static exports. ## create-parcel CLI To help setup new projects more quickly, Parcel now includes a `create-parcel` CLI that scaffolds a project from a template. For example, to create a new React Server Components project, run the following command: ```bash npm create parcel react-server my-rsc-app ``` This will create a new `my-rsc-app` directory, initialize a Git repo, scaffold boilerplate files, and install dependencies. Currently there are 4 templates: * `vanilla` – a Vanilla JS + HTML app * `react-client` – a TypeScript + React client only app. See [Parcel's React docs](/recipes/react/). * `react-server` – a TypeScript + React Server Components app. See [Parcel's React Server Components docs](/recipes/rsc/). * `react-static` – a TypeScript + React static site generator. See [Parcel's React Server Components docs](/recipes/rsc/). We will add additional templates in the future for other frameworks and setups. ## Create React App migration Recently, the React team [deprecated Create React App](https://react.dev/blog/2025/02/14/sunsetting-create-react-app) for new apps. Existing apps are encouraged to migrate to another framework or build tool like Parcel. To help make assist with this, we now have official [migration docs](/migration/cra/) describing how to migrate from CRA to Parcel. In addition, these steps are automated via our new [cra-to-parcel](https://github.com/parcel-bundler/cra-to-parcel) script. ```bash npx cra-to-parcel ``` This migrates your dependencies, configuration, and source code to use Parcel. If you run into any issues during this process, please [file an issue on Github](https://github.com/parcel-bundler/cra-to-parcel/issues). ## New React error overlay In React apps, Parcel includes an error overlay that displays runtime errors with a nice UI containing inline code frames. We previously used the `react-error-overlay` package from Create React App to implement this. As mentioned above, CRA is now officially deprecated, and `react-error-overlay` has been unmaintained for some time. In this release, we forked and modernized the error overlay and integrated it deeper with Parcel. Previously, the error overlay implemented its inline code frames using source maps. When an error occured, it parsed the stack trace, loaded the relevant source maps in the browser, and mapped each line in the stack to a code frame with syntax highlighting. This is quite intensive to implement in the browser, often requiring many network round trips and expensive source map parsing logic. The Parcel dev server now exposes an internal endpoint to do all of this, instead of doing it in the browser. This improves performance since source mapping logic can be implemented in Rust, and there are no network round trips. In addition, with React Server Components, errors that occur in server code will also appear in the same error overlay, and React hydration errors are displayed with colorized diffs. ## Native HTML import maps Parcel now uses native [HTML import maps](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap) to implement its bundle manifest when supported by your browser targets. Parcel's bundle manifest helps avoid [cascading cache invalidation](https://philipwalton.com/articles/cascading-cache-invalidation/). Instead of directly referencing dynamically loaded bundles by URL which may include a changing content hash (e.g. `import("./some-bundle.fh36va.js")`), Parcel uses a stable bundle id (e.g. `import("af43fx")`). This id is mapped to a URL at runtime through a bundle manifest. This way, when the content hash of the referenced bundle changes, it does not _cascade_ to all bundles that reference it as well. Previously, Parcel implemented a custom bundle manifest in JavaScript. This was placed in each entry JavaScript bundle of your app. Therefore, when a dynamically loaded bundle changed, only that bundle and the entry bundles would be invalidated in browser caches. Parcel now uses native HTML import maps to implement the bundle manifest when possible. Parcel injects a ` ``` {% endsamplefile %} {% samplefile "home.js" %} ```jsx import { createRoot } from 'react-dom'; createRoot(app).render(

Home

, app); ``` {% endsamplefile %} {% samplefile "profile.html" %} ```html
``` {% endsamplefile %} {% samplefile "profile.js" %} ```jsx import { createRoot } from 'react-dom'; createRoot(app).render(

Profile

, app); ``` {% endsamplefile %} {% endsample %} Compiled HTML: {% sample %} {% samplefile "home.html" %} ```html
``` {% endsamplefile %} {% samplefile "profile.html" %} ```html
``` {% endsamplefile %} {% endsample %} In the above example, both `home.js` and `profile.js` depend on `react-dom`, so it is split out into a separate bundle and loaded in parallel by adding an extra `