universal-redux
nx
| universal-redux | nx | |
|---|---|---|
| - | 370 | |
| 463 | 25,432 | |
| - | 2.8% | |
| 1.1 | 10.0 | |
| almost 4 years ago | 1 day ago | |
| JavaScript | 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.
universal-redux
We haven't tracked posts mentioning universal-redux yet.
Tracking mentions began in Dec 2020.
nx
-
Frontend Monorepos: A Comprehensive Guide
Nx Documentation: https://nx.dev/ - Official documentation for the Nx build system.
-
UmiJS: the Shaolin of web frameworks
🏗️ The Umi's plugin system and API is quite interesting. You can do a lot with that. The approach is quite common for dev tools and in this case resembles both Vite and Nx with their extensibility and community orientation. There's a huge ecosystem of plugins of all sorts, and you can always complement them with your own (which is quite important for sophisticated enterprise development). I'd assume you could build pretty decent metaframework mechanisms with this flexible approach. At least, as I mentioned already, you have a bunch of thoughtful building blocks for that.
-
Building EczEase with Cutting-Edge Tech - Introduction
Nx is our choice for managing the project's monorepo structure. It provides powerful tools for scaling our development process, ensuring code reusability, and maintaining consistency across different parts of the application. With Nx, we can efficiently manage multiple projects within the EczEase ecosystem, from the main web application to potential mobile apps and backend services.
-
Why I Swapped NX for Standalone Projects
Hello! I used to like NX a lot. It was a monorepo for all my projects—different brands and clients in one place. It worked well, but it didn’t suit me. Most of my projects are single Angular apps. So, I stopped using one big NX repo and made separate projects instead. Here’s why I prefer it.
-
The Final (For Now) Setting for My Personal Blog as a Dev
The project is using Nx workspace + PNPM for package management
-
Micro-Frontends: The Next Big Thing or Just Hype?
Then there’s the tooling. Micro-frontends aren’t as plug-and-play as a monolith yet. You’ll likely need custom build pipelines, deployment scripts, and a solid CI/CD setup. Tools like Nx can help here—its monorepo approach is a lifesaver for managing multiple micro-frontends in one cohesive workspace. Their micro-frontend guide is worth a peek if you’re curious.
-
CodeMash 2025
Nx (sponsored the Lightning Talks)
-
I'll think twice before using GitHub Actions again
Caching and sharing artifacts is usually the main culprit. My company has been using https://nx.dev/ for that. It works locally as well and CI and it just works.
Our NX is pointed to store artifacts in GHA, but our GHA scripts don't do any caching directly, it is all handled by NX. It works so well I would even consider pulling a nodejs environment to run it in non-nodejs projects (although I haven't tried, probably would run into some problems).
It is somewhat heavy on configuration, but it just moves the complexity from CI configuration to NX configuration (which is nicer IMO). Our CI pipelines are super fast if you don't hit one of one of our slow compilling parts of the codebase.
It is quite interesting is that your local dev environment can pull the cached items there were build from previous CI ran-jobs or other devs. We have some native C++ dependencies that are kind of a pain to build locally, our dev machines can pull the built binaries built by other devs (since all devs and CI also share the same cache-artifacts storage). So it makes developing locally a lot easier as well, I don't even remember last time I had to build the native C++ stuff myself since I don't work on it.
-
Custom builder for Angular: My way
An efficient work environment is the key to rapid development and testing. Many of us have heard stories about how it takes days or even weeks to set up a work environment at a new job or project. I am not exception! To avoid such situations, I decided to think through the structure and configuration in advance. The main idea was to make everything reproducible and easy to use. Since the goal was to develop a plugin for nx.dev, I started by creating a new workspace via create-nx-workspace. I used the test application to experiment with SSR, and therefore created a plugin template using @nx/plugin:plugin. Additionally, I generated two applications and one library via NX generators. As a result, the project structure looked like this:
-
Monorepo and Micro-Frontends Using Module Federation + Vite
Nx Documentation Vite Documentation Webpack Module Federation Micro-Frontend Architecture
What are some alternatives?
nwb - A toolkit for React, Preact, Inferno & vanilla JS apps, React libraries and other npm modules for the web, with no configuration (until you need it)
nestjs-monorepo-microservices-proxy - Example of how to implement a Nestjs monorepo with no shared folder
reactpack - :package: build your react apps with one command and one `npm i`.
turborepo - Incremental bundler and build system optimized for JavaScript and TypeScript, written in Rust – including Turborepo and Turbopack. [Moved to: https://github.com/vercel/turbo]
create-react-dependency - Project similar to the Create React App for libraries and dependencies
lerna - Lerna is a fast, modern build system for managing and publishing multiple JavaScript/TypeScript packages from the same repository.