Our great sponsors
-
Snowpack
Discontinued ESM-powered frontend build tool. Instant, lightweight, unbundled development. ✌️ [Moved to: https://github.com/FredKSchott/snowpack] (by withastro)
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
react-query
Discontinued 🤖 Powerful asynchronous state management, server-state utilities and data fetching for TS/JS, React, Solid, Svelte and Vue. [Moved to: https://github.com/TanStack/query]
-
nivo
nivo provides a rich set of dataviz components, built on top of the awesome d3 and React libraries
-
webpack-bundle-analyzer
Webpack plugin and CLI utility that represents bundle content as convenient interactive zoomable treemap
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Why it's so fast? because it's written in go and does a lot of optimizations. ES modules is a new browser feature that enables to natively load modules - meaning no need to bundle everything in one giant bundle. We can split the code into smaller modules and load them as needed. This helps avoid unnecessary work and stay fast no matter how big the project grows.
It did not take a lot of time to choose the tool. Currently, there are 3 major bundlers powered by ESM - vite, snowpack, and wmr. From the first glance - all of them look promising and I did not care about their internals as long as I don't need to touch them.
My conclusion is that if you won't need SSR (which experimentally supported in vite), I encourage you to try vite / other ESM build tools. It will make your dev environment really fast. Start with the docs, Skim https://github.com/vitejs/awesome-vite and look at the open issues too. It will make your dev environment really fast.
It did not take a lot of time to choose the tool. Currently, there are 3 major bundlers powered by ESM - vite, snowpack, and wmr. From the first glance - all of them look promising and I did not care about their internals as long as I don't need to touch them.
We already have configured path aliases with webpack and tsconfig - so I wanted to keep that behavior. Luckily we have the vite-tsconfig-paths exactly for that. It worked well. I could also try using the alias for that.
We already have configured path aliases with webpack and tsconfig - so I wanted to keep that behavior. Luckily we have the vite-tsconfig-paths exactly for that. It worked well. I could also try using the alias for that.
Instead of webpack svgr - vite has a community plugin vite-plugin-svgr. Looking at its source code I can tell that it does the work as needed. In the future, I may want to add more SVGR options (currently for custom colors we use css currentColor property), so I may contribute it or create a similar plugin. NOTE: vite bundles the static svg in addition to assets even if you use vite-plugin-svgr. So many useless files will be generated. This is a minor issue that can be unnoticeable. I created a script for deleting those files (it has 0 impacts on the bundle because the client does not download those chunks).
Instead of webpack svgr - vite has a community plugin vite-plugin-svgr. Looking at its source code I can tell that it does the work as needed. In the future, I may want to add more SVGR options (currently for custom colors we use css currentColor property), so I may contribute it or create a similar plugin. NOTE: vite bundles the static svg in addition to assets even if you use vite-plugin-svgr. So many useless files will be generated. This is a minor issue that can be unnoticeable. I created a script for deleting those files (it has 0 impacts on the bundle because the client does not download those chunks).
Small issue with react-query devtools that solved by changing to a different minor version. But it's more an issue with the library.
react-markdown v4 also has an issue using process.cwd internally. I upgraded to v5 and the problem is gone. It seems that like in webpack 5 - you won't get and node.js polyfills with vite.
Some third-party libraries like nivo for graphs use internally Node.js specific global keyword (here). But ES modules do not support it - and we get a Reference not found error for global variable. What vite tries to do is to convert them to be ESM - and run them in the browser. But the browser does not know what global is - so it fails. At first, I try to handle this in vite.config.ts with define - setting global: {} . But doing so created a problem with import GlobalStyles from "./global.style" then converted to be unwanted import GlobalStyles from "./{}.style" . So until nivo will upgrade to ES-modules - I hacked that global variable by pre-load in index.html like
In our "old" build system - I configured webpack-bundle-analyze to inspect bundle chunks and understand what it made of. I added rollup-bundle-visualyzer instead (although there is an issue that the reported size is not correct).
In our "old" build system - I configured webpack-bundle-analyze to inspect bundle chunks and understand what it made of. I added rollup-bundle-visualyzer instead (although there is an issue that the reported size is not correct).
I will change the as Plugin type assertion when my PR to @types/rollup-bundle-visualyzer will be merged
My conclusion is that if you won't need SSR (which experimentally supported in vite), I encourage you to try vite / other ESM build tools. It will make your dev environment really fast. Start with the docs, Skim https://github.com/vitejs/awesome-vite and look at the open issues too. It will make your dev environment really fast.