Parcel Plugin Prerender

Parcel Plugin Prerender
Alternatives To Parcel Plugin Prerender
Project NameStarsDownloadsRepos Using ThisPackages Using ThisMost Recent CommitTotal ReleasesLatest ReleaseOpen IssuesLicenseLanguage
Typescript Plugin Css Modules1,028261909 days ago37June 05, 202111mitTypeScript
A TypeScript language service plugin providing support for CSS Modules.
Baklavajs830158 days ago39May 21, 202237mitTypeScript
Graph / node editor in the browser using VueJS
22 months ago16May 01, 2018103otherJavaScript
Make maps with OpenStreetMap and Mapnik
2 years ago6August 02, 20211unlicenseC++
Spout plugin for Unity
5 years agomitJavaScript
Modern infrastructure of complex SPA :
Hexo Renderer Markdown It28514811a month ago29February 05, 202212mitJavaScript
Markdown-it is a Markdown parser, done right. A faster and CommonMark compliant alternative for Hexo.
2 years ago33mitPython
appleseed plugin for Blender
Chartjsnodecanvas1986142 months ago42January 18, 202227mitTypeScript
A node renderer for Chart.js using canvas.
Calibre Kobo Driver178
8 months ago1gpl-3.0Python
An extension of the existing KoboTouch driver provided with Calibre. This plugin allows modifying ePub files to enable extra Kobo features. I am providing code in the repository to you under an open source license. Because this is my personal repository, the license you receive to my code is from me and not my employer.
Hexo Renderer Marked1519,149464 months ago27January 29, 20227mitJavaScript
Markdown renderer for Hexo
Alternatives To Parcel Plugin Prerender
Select To Compare

Alternative Project Comparisons


Known Vulnerabilities


Much like the prerender-spa-plugin for Webpack, this plugin is to bring prerendering capabilities to Parcel. It is meant to be a drop-in solution for any site or single-page-app.


npm install parcel-plugin-prerender -D


By default, this plugin will render the / path when building with parcel (i.e. parcel build or process.env.NODE_ENV == "production"). As this plugin uses cosmiconfig, in order to configure the plugin, pass the configuration options in a prerender key in your package.json, or a JSON or YAML .prerenderrc file, or export the config object in a prerender.config.js file.


If you just want to render multiple routes, you can pass a plain array in any of the above ways:

// .prerenderrc
["/", "/about", "/login", "/deep/nested/route"]

Otherwise, you must pass it in a routes key, in order to configure the renderer, as follows.

Render configuration

You can configure the renderer (browser) options by using the following example config:

  "routes": ["/", "/about"],
  "rendererConfig": {
    "renderAfterDocumentEvent": "prerender-trigger"

This is particularly useful if you'd like to pre-fetch some API data or async config and make that part of your pre-rendered HTML.

In the example above, the / and /about pages will only be rendered when the custom DOM event prerender-trigger is dispatched.

You can do so in your code like the following:

document.dispatchEvent(new Event('prerender-trigger'));

The custom configuration can also be useful for debugging. If the resulting html does not look like what you're expecting you could use the following configuration:

  "routes": ["/", "/about"],
  "rendererConfig": {
    "headless": false

To make the pre-render browser visible and you would be available to debug.

To see all the options available see this documentation

What is Prerendering?

To quote prerender-spa-plugin:

Recently, SSR (Server Side Rendering) has taken the JavaScript front-end world by storm. The fact that you can now render your sites and apps on the server before sending them to your clients is an absolutely revolutionary idea (and totally not what everyone was doing before JS client-side apps got popular in the first place...)

However, the same criticisms that were valid for PHP, ASP, JSP, (and such) sites are valid for server-side rendering today. It's slow, breaks fairly easily, and is difficult to implement properly.

Thing is, despite what everyone might be telling you, you probably don't need SSR. You can get almost all the advantages of it (without the disadvantages) by using prerendering. Prerendering is basically firing up a headless browser, loading your app's routes, and saving the results to a static HTML file. You can then serve it with whatever static-file-serving solution you were using previously. It just works with HTML5 navigation and the likes. No need to change your code or add server-side rendering workarounds.

In the interest of transparency, there are some use-cases where prerendering might not be a great idea.

  • Tons of routes - If your site has hundreds or thousands of routes, prerendering will be really slow. Sure you only have to do it once per update, but it could take ages. Most people don't end up with thousands of static routes, but just in-case...
  • Dynamic Content - If your render routes that have content that's specific to the user viewing it or other dynamic sources, you should make sure you have placeholder components that can display until the dynamic content loads on the client-side. Otherwise it might be a tad weird.

Available Renderers

Currently only @prerenderer/renderer-puppeteer is supported, although @prerenderer/renderer-jsdom will probably be supported in the future

Popular Plugin Projects
Popular Renderer Projects
Popular Libraries Categories
Related Searches

Get A Weekly Email With Trending Projects For These Categories
No Spam. Unsubscribe easily at any time.
Static Site Generator