Skip to main content

· 2 min read

Attendees: Ian, Milan Kovacic

Date: 2024-04-10

Meeting Agenda

  • Discussed create-single-spa PR 402
  • Milan plans to introduce nx to create-single-spa
  • Ian will look into fixing the types in single-spa-layout
  • Joel will push towards single-spa@7

Note from single-spa's creator

After releasing single-spa@7, I think my next priority for single-spa will be to push for native ES modules and native import maps.

I lean against es-module-shims because I don't think we need those additional features, and am hesitant about in-browser parsing of the Javascript language being something that is encouraged in production (despite the performance metrics on the readme suggesting that it's negligible). I want single-spa to be as native to the browser as possible.

The recommendation should be to use a single inline import map, rather than multiple import maps or an external import map, for performance reasons. For cases where that isn't possible, I think should be used, since it doesn't parse JS in the browser.

Regarding shared dependencies, I think we should discuss whether to support self hosting or just JSPM proxies. I imagine some users will insist on self-hosting, which means we could check if JSPM is open source or if there is a similar tool for converting npm packages to ES modules.

Regarding module federation, I discussed it with Zack and module federation is still moving towards a runtime rather than native import maps. There might be possible collaboration on a service worker for module federation + native modules. I personally prefer no runtime whatsoever - just what the browser natively supports.

· 8 min read

With rapid growth in recent years, microfrontends have become a popular solution with many companies, from large software organizations to small independent dev teams. Microfrontend hosting can get complicated quickly but it is a crucial aspect of scaling software organizations' development cycle. Whether companies are using single-spa, module federation, or any other microfrontends tools, the management of CI/CD pipelines, deployments, CDNs, and service discovery is something all companies will have to solve.

So what’s the most effective solution? Because microfrontend hosting is a relatively new space, most companies have a hard time knowing where to start. Fortunately, there are very good options out there, and unless you have a good reason to, you don’t have to build it out yourself. Here you’ll find a list of the best hosting solutions and the important factors you’ll need to consider to make the decision.

Server-side versus client-side rendering

This article focuses on hosting solutions for client-side rendered microfrontends, since the majority of microfrontend implementations rely solely on client-side rendering.

Server-side rendering of microfrontends often involves one or more docker containers that run NodeJS to render React, Angular, or Vue applications. For optimal performance, single-spa server rendering also supports a single NodeJS runtime (rather than network requests between docker containers).

If your organization uses server-side rendering, the following rankings will still apply but may require some additional consideration that isn’t covered here.

Low-level vs high-level hosting solutions

Hosting microfrontends can be accomplished with lower-level cloud services (AWS, GCP, Azure, etc) or via microfrontend-specific cloud hosting solutions such as Baseplate Cloud and Zephyr Cloud. Lower-level services may be more affordable but require much more initial setup and ongoing maintenance. Higher-level microfrontend hosting solutions provide targeted features to streamline the hosting and development process.

Companies who wish for sensible defaults and a straightforward implementation path may choose higher-level hosting solutions to save on DevOps and system admin costs. The additional built-in features of higher-level hosting solutions often reduce implementation time for companies migrating to or starting with microfrontends.

Solution comparison

Baseplate CloudZephyr CloudS3 + CloudfrontGCP Storage + Cloud CDNAzure Storage + CDN
Global availability✓ (via Cloudflare)✓ (Cloudflare / Netlify)
Web app hosting 1
Environments support 2(manual)(manual)(manual)
Autogenerated CI pipelines 3(planned)
Automated microfrontend creation✓ (via API and CLI)(manual)(manual)(manual)
Custom domains✓ (via DNS records)
Route / layout management 4✓ (single-spa-layout template)(manual)(manual)(manual)(manual)
Self-owned assets storage 5✓ (optional bring-your-own-s3-bucket)
Edge-side HTML rendering optimizations 6(planned)
Service discovery 7(manual)(manual)(manual)
CORS / CSP / Cache Control✓ (sensible defaults, fully customizable)(planned)
Usage metrics(planned)(manual)(manual)(manual)
Full audit trail 8(manual)(manual)(manual)
Permissions management✓ (comprehensive, including microfrontend ownership)
Shared dependency management 9(planned)(manual)(manual)(manual)
Server rendering support(planned)(planned)
Microfrontend marketplace 10(planned)(planned)
Rolling deployments 11(planned)(planned)
  1. Web apps hosting refers to hosting the parent/root HTML file that initializes the microfrontends necessary for client-side rendering.
  2. Environment support refers to hosting each microfrontend and web app on both internal test environments and live production environments. CI/CD Pipelines are configured to deploy to environments sequentially.
  3. Auto-generated CI pipelines refers to generating configuration files for Github workflow, Azure Pipelines, Gitlab CI and other CI/CD tools.
  4. Route / layout management refers to managing the in-browser URL routes and DOM layout for microfrontends.
  5. Self-owned assets storage refers to JS, CSS, HTML, font, and image files being stored within a bucket owned by the company implementing microfrontends, rather than by cloud hosting service.
  6. Edge-side HTML rendering optimizations refers to dynamically changing the HTML file for a web app via code that runs in edge locations. Since edge locations are physically closer to most users than an origin server, this provides maximum performance beneifts. Performance benefits include inlining import maps, <link rel=preload>, and <script> elements so that the browser begins downloading the necessary resources for the current URL as quickly as possible.
  7. Service discovery refers to all available microfrontends easily cross-communicating with each other. This is often done via import maps or other manifest files.
  8. Full audit trail refers to logs for all deployments, infrastructure changes, and configuration changes within the microfrontends system.
  9. Shared dependency management refers to externalizing or federating shared npm packages between microfrontends, to improve performance by only downloading and executing the code for them once within a web page.
  10. Microfrontend marketplace refers to purchasing or installing pre-made microfrontends into a company's system.
  11. Rolling deployments refers to introducing new code changes to a microfrontend to only a fraction of the userbase, to minimize impact of releasing bad code.

1. Baseplate Cloud

Baseplate Cloud tops the list for its ease of use and specific focus on single-spa hosting. Because it was made by the creator of single-spa, Baseplate's features have been informed by years of microfrontend and single-spa consultancies, making it the easiest microfrontend hosting choice for single-spa. Everything about the product simplifies and automates as much of the complexity as possible, and it’s hard to find advantages in other solutions that beat this fact. Baseplate will probably be the best choice for any company that is prioritizing a streamlined cloud hosting experience.

Baseplate's feature set automates the job functions of multiple software developers and frees up a lot of development resources without increasing the size of the development team. This easily offsets the cost of Baseplate's services.

Baseplate supports the following features:

  • Web apps hosting
  • Custom domains for web apps and static assets
  • Unlimited deployable environments
  • Unlimited microfrontends
  • Autogenerated CI/CD pipelines
  • Full audit trail
  • Microfrontend-specific usage metrics
  • CORS, CSP, and Cache-Control configuration
  • Edge-side performance optimizations

Also of note, Baseplate CDN is a source-available Cloudflare worker designed for maximum performance and best practices. It is globally available at all Cloudflare edge locations.

2. Zephyr Cloud

From the creators of Module Federation, Zephyr Cloud is the premier hosting solution for module-federation-based microfrontends. It is currently in closed alpha with little publicly documented about its features.

3. AWS S3 + Cloudfront

Amazon Web Services (AWS) offers the low-level cloud services necessary for companies to set up a microfrontends hosting solution. The most common microfrontends hosting solution within AWS often involves a Cloudflare distribution that acts as a public CDN, with a private S3 bucket as the origin containing all static web files (Javascript, CSS, HTML) needed.

The advantage of using lower-level cloud hosting services is their initial lower costs—however, that comes at the expense of increased setup and maintenance complexity compared to microfrontend-specific cloud hosting solutions.

Implementation details will vary from company to company. It's common for each microfrontend's files to be stored within a (virtual) folder within the s3 bucket and the manifest or import map listing all microfrontends made available in a JSON file. Web apps using the microfrontends may have their own S3 bucket or be within the same S3 bucket.

4. GCP Storage + Cloud CDN

Google Cloud Platform provides equivalent low-level cloud services to AWS. The same technical details that apply to AWS S3 + Cloudfront also apply to GCP Cloud Storage and GCP Cloud CDN.

5. Azure Storage + CDN

Azure Storage provides equivalent low-level cloud services to AWS. The same technical details that apply to AWS S3 + Cloudfront also apply to Azure Storage and GCP Cloud CDN.

· 2 min read

Attendees: Joel Denning, Milan Kovacic

Date: 2024-03-13

Meeting Agenda

  • Typescript migration: single-spa@7 - typescript, IE11, navigation cancelation
  • Migration from SystemJS to native modules - use es-module-shims??
  • Discuss creation of single-spa CLI
  • Getting started documentation being updated by Milan
  • Discuss future of shared dependency management

TypeScript Migration

Fifth typescript PR has been merged ( Sixth one on the way

Migration to native modules

Discuss the limitations of native modules and import maps (external import maps, external import maps, etc). Discuss whether to use import-map-injector or es-module-shims or neither. Joel expressed concern about runtime parsing of modules, but Milan pointed out that Ruby on Rails as adopted es-module-shims. We looked at the performance benchmarks for es-module-shims, which show it's only a 5ms difference compared to native modules.

We also discussed possible collaboration with Zack Jackson on module federation's new runtime (called MFP) and whether that could help. Also discuss whether a service worker would be necessary or helpful to hook into the browser's loading of modules.

single-spa CLI

See single-spa issue 1205 for Milan's proposal. Joel has hesitations about abstracting away bundler config and configuration files, but we decided to proceed with Milan's proposal, since developer experience is one of the main barriers to entry for developers and corporations who are used to managed configuration in other projects (NextJS, Vite, etc etc). The main concern is how to do it in a way where single-spa users don't have to go digging in node_modules regularly to be able to do what they need to do to their projects.

Shared dependencies management

Baseplate Cloud plans to use JSPM CDN for native ES module shared dependencies. Managing the dependencies in the import map over time is important to do in a sensible way that avoids accidentally breaking production, while still allowing for incremental migration of dependencies on microfrontend at a time.

We didn't decide on anything concrete - just brainstormed solutions. Ideally the open source ecosystem can self-host shared dependencies as well.

· One min read

Attendees: Joel Denning, Milan Kovacic, Ian Bacher, Jake Hayes

Meeting Agenda

  • TypeScript migration
    • single-spa
    • single-spa-react
  • Maintenance update
  • Baseplate
  • Roadmap items
  • Blog posts

TypeScript Migration

  1. Single-spa-layout broken types
  2. New PR for migration Single-spa

Review other PR's

  1. Examination of an open PR to fix Issue #1184
    1. Discussed introducing a new potential lifecycle hook

Baseplate Pricing Feedback

  • Maybe indicate that GB storage is optional. It's possible to bring your own
  • "The prices are not ridiculous" - Ian
  • "The prices seem reasonable, and the descriptions make sense" - Jake

Roadmap Items

  • Removing default exports
  • single-spa-playground was broken due to DNS records, Joel was able to fix that last week
  • Look into CORS for single-spa-playground - @Ian will look into

Blog posts

  • Potentially adding Baseplate specific blog posts to single-spa

· One min read

Attendees: Joel Denning Jake Hayes, Milan Kovacic

Achievements and Progress from December

January 2024 Roadmap

  1. Migrate main single-spa project to typescript. See issue 1185, PR 1186 and PR 1187.
  2. Continue work on the consolidation and updates of the example projects
  3. Review

Meeting Notes

Initiatives and Goals

  • Adding unit tests to existing projects
  • SystemJS -> ESM migration
  • create-single-spa update (
  • Release single-spa 6 as latest ✅
  • Improve shared dependencies management
  • Autopublishes to npm
  • Server rendering enhancements?
  • Support for NextJS, NuxtJS, Remix, create-react-app, and other build tools
  • Consolidate example projects 🚧
  • Feature voting
  • Automated integration tests for popular frameworks
  • Update create-single-spa dependencies 🚧

· One min read

Attendees: Artur Androsovych, Ian Bacher, Jake Hayes, Milan Kovacic

Achievements and Progress from November

  • Successfully released single-spa version 6, marking a significant milestone in the project's development

December 2023 Roadmap

  1. Update dependencies, and set up automation, starting with create-single-spa
  2. Continue work on the consolidation and updates of the example projects

Meeting Notes

  • Welcomed Ian Bacher as a new addition to the core team.
  • Reviewed single-spa roadmap

Initiatives and Goals

  • Adding unit tests to existing projects
  • SystemJS -> ESM migration
  • create-single-spa update (
  • Release single-spa 6 as latest ✅
  • Improve shared dependencies management
  • Autopublishes to npm
  • Server rendering enhancements?
  • Support for NextJS, NuxtJS, Remix, create-react-app, and other build tools
  • Consolidate example projects 🚧
  • Feature voting
  • Automated integration tests for popular frameworks
  • Update create-single-spa dependencies 🚧

· 10 min read

We have released single-spa@6! The single-spa core team is committed to a stable single-spa runtime with very few breaking changes. We expect over 95% of single-spa users can upgrade easily without altering their changes!

Note from single-spa's creator

On September 22, 2015, I pushed single-spa's initial commit. 8 years later, I am releasing single-spa@6. I am committed to this project and hope to improve and grow it for many years to come. The single-spa core team recently started monthly calls where we discuss important pull requests and roadmap (see first meeting notes). The future of microfrontends still includes single-spa.

On December 11, 2023, the company I founded is launching a product called Baseplate Cloud that offers single-spa hosting. Baseplate Cloud is the single-spa hosting solution born from 4+ years of consulting with various companies who were implementing single-spa. Baseplate CDN is a Cloudflare worker that proxies JS files from cloud storage, provides edge-side import map processing, auto-implements single-spa root configs, and more. Cloudflare edge-side processing provides many performance advantages while retaining the impressive scalability and security of Cloudflare. As a sign of good will towards the open source and single-spa communities, I have kept the baseplate-cloudflare-worker public, with a "Commons Clause" + AGPL 3.0 license. Companies can use and contribute to baseplate-cloudflare-worker freely, as long as they don't try to sell it in competition to Baseplate Cloud. I would appreciate the community's backing and hope Baseplate becomes the way to financially sustain the single-spa project in the long term.

It would mean the world to me if your company or organization considered signing up for Baseplate's paid, private beta launch. We used the revenue the community gave us for to create Baseplate, and plan to use Baseplate revenue to fund maintenance of single-spa's open source ecosystem. The Baseplate team is proudly a worker-owned business that has not sacrificed ownership of the company to outside investors. We built Baseplate with the revenue the community gave us via as the initial funding, which is only a few thousand dollars a month. The best Christmas present I could receive this year is a few dozen companies signing up immediately and putting Baseplate on their Q1 or Q2 roadmaps for 2024. I am asking for corporate partners to ensure long term financial sustainability so that single-spa will remain a good microfrontends solution for years to come.

Contact Baseplate Sales


single-spa@6 provides advanced features such as async navigation cancelation and parcel-only mode (via patchHistoryApi), while also updating the package configuration to use modern NodeJS and bundler features like package entrypoints and "type": "module". We also updated urlRerouteOnly to default to true, as it boosts performance and we consider it to be a best practice to author applications that work when urlRerouteOnly is set to true.

Browser Support / IE11

We still support IE11 and the same versions of NodeJS (at least as old as Node 10). However, we've changed our defaults such that IE11 is only supported with some additional configuration, as described in the IE11 Migration section below.

For the single-spa npm package, we plan single-spa@6 to be the last major version that supports IE11. In general, we've released a major version of single-spa every 1-2 years. We do not have a concrete timeline or plans for single-spa@7, and will accept community contributions for any important patches to single-spa@6 after single-spa@7 is released.

For all surrounding packages (single-spa-react, single-spa-vue, systemjs-webpack-interop, single-spa-angular, etc) we may begin dropping IE11 support sooner than the single-spa@7 release. As we do so, we'll create documentation that lists the latest versions of packages that support IE11, and also accept community contributions to those versions for important updates.

The motivation for dropping IE11 support over time is to allow our core team to spend less time on supporting a nine year old browser and more time pushing the single-spa ecosystem forward. Also, we believe that the majority of end users should not suffer performance penalties because of a small percentage of users still using IE11. Slowly dropping IE11 also will also allow us to focus on a systemjs-less future for single-spa, where native browser modules are used rather than systemjs modules.

We understand and sympathize with companies who cannot drop IE11 support now, which is why we're supporting IE11 even though much of the ecosystem has already dropped it (Vue 3 does not support ie11, Angular only does after some effort, and even webpack 5 requires extra configuration to get it working in IE11). Many of single-spa's users are large financial institutions, large ecommerce companies, and other very large companies, where dropping IE11 support is a long process that involves many dozens of people from separate departments. We encourage single-spa users to start the conversations at your companies about dropping IE11 support, even if they take a long time or result in a decision to drop IE11 years in the future.


We think that >95% of single-spa users will be able to safely upgrade with no code changes. The breaking changes below are largely related to advanced features that most single-spa users do not use.


  1. If using SystemJS + import maps, change the URL of single-spa in your import map:
<script type="systemjs-importmap">
"imports": {
- "single-spa": ""
+ "single-spa": ""
  1. In all your microfrontends (including root config), upgrade single-spa:
npm install single-spa@6
yarn add single-spa@6
pnpm install single-spa@6
  1. Test things out.
  2. If your app is not re-rendering during route transitions like it should (this is most common for Angular apps, but can happen in other frameworks to if you do a route transition without modifying the URL), change your root config's call to start()
import { start } from 'single-spa';

// DO NOT MAKE THIS CHANGE unless you are experiencing problems.
- start();
+ start({
+ urlRerouteOnly: false
+ });

That's it! If you experience other issues, let us know in Github issues.


If you support IE11, use the es5 version of single-spa rather than es2015. The method of doing this depends on your configuration - some common ones are explained below:

Import Maps

<script type="systemjs-importmap">
"imports": {
- "single-spa": ""
+ "single-spa": ""


If externalizing single-spa in your webpack config (very common, and the default with webpack-config-single-spa), you do not need to make the changes below. Otherwise, though, these changes will ensure you use the IE11-compatible version of single-spa.

// webpack.config.js
module.exports = {
resolve: {
alias: {
"single-spa": require.resolve("single-spa/lib/es5/esm/single-spa.min.js"),


Use to alias the import similarly to webpack


If you do not wish to change bundler configuration, you can modify your import statements.

- import { start } from 'single-spa';
+ import { start } from 'single-spa/lib/es5/esm/single-spa.min.js';

Breaking Changes

  • single-spa's package.json's "main" field now points to an es2015 version of single-spa that does not work in IE11. To support IE11, see section below.
  • Delay patching history api until start() or patchHistoryApi() is called. Github link
  • Do not show start() warning when registerApplication hasn't been called (for parcel-only use cases) Github link
  • Change urlRerouteOnly default value to true. This is a performance boost for most applications, but for some situations can result in single-spa not triggering mounts/unmounts when it should. You can read more about it at and Angular users may want to set it to false due to nuanced behavior of angular router. To do so, call start({urlRerouteOnly: false}) in your root config. Github link
  • cancelNavigation(val) no longer cancels navigation if val is falsy Github link
  • single-spa's package.json "type" is now set to "module". This only impacts NodeJS usage of single-spa (not webpack/rollup/browser). Read more at official nodejs docs.
  • single-spa's package.json now has "exports". This changes which of single-spa's bundles are used by NodeJS, webpack, and rollup. The main change is that webpack / rollup will now use an IE11-incompatible (es2015) version of single-spa. See IE11 section below for more details. Additionally, an ESM version of single-spa will now be used when loaded via import('single-spa') or import 'single-spa';, whereas a UMD version will be used when calling require("single-spa'). To avoid the dual package hazard, only use import or require to load single-spa in your NodeJS code - do not use both. You can see the package exports at
  • The published umd builds now have .cjs extensions rather than .js, since all .js files in the single-spa package are assumed to be ESM.
File structure published to npm

# Before
# See
# IE11
# IE11
# IE11
# No IE11

# After
# See
# IE11
# No IE11


Async navigation cancelation

We've added support for async navigation cancelation. To use it, call cancelNavigation(promise) with a promise as an argument. Single-spa will wait until that promise resolves/rejects before proceeding with navigation. If the promise resolves with a truthy value, navigation is canceled. If the promise resolves with a falsy value or rejects, navigation is not canceled. Github link

window.addEventListener("single-spa:before-routing-event", (evt) => {
if (evt.detail.oldUrl === "/settings") {

async function checkSettingsOkay() {
const response = await fetch("/api/settings-okay");
if (response.ok) {
return true;
} else {
alert("Please fix your settings before leaving the page");
return false;

New patchHistoryApi

We've exposed a new patchHistoryApi() api. This lets you use single-spa's modified implementations of pushState/replaceState/popstate/hashchange without using single-spa applications. This is intended to be used by single-spa users who exclusively use single-spa parcels, rather than applications Github link

import { patchHistoryApi, mountRootParcel } from "single-spa";

urlRerouteOnly: true,

// now you don't need to call start() if you're only using parcels

mountRootParcel(parcelConfig, parcelProps);

New profiler

We've implemented a profiler that is available within the dev builds of single-spa@6. A visualization of the profiler is available in the single-spa-inspector@0.6.0 browser extension:

  • Implement profiler for lifecycle events. by @joeldenning in #868
  • Implement parcel and routing profiler events. by @joeldenning in #903
Screenshot of single-spa-inspector profiler tab


  • Fix regression with parcel name Github link
  • Ensure all reroute promises (triggerAppChange() return value) resolve even during cancelation Github link
  • fix(types): fix SingleSpaAppsByNewStatus interface by @FelixGraf in #988
  • Ensure app is unmounted during unregisterApplication. Resolves #871 by @joeldenning in #875


  • Switch from yarn -> pnpm Github link
  • Upgrade all dependencies Github link
  • Upgrade husky from v4 to v7. Use pinst to avoid issues with yarn 2 users as described in Github link
  • Upgrade to Jest 27. Fix tests to work with Jest 27. Github link
  • Upgrade to Node 16. Fix tests to work with Node 16 (Fix tests in Node 15 #652) Github link
  • Run upgraded version of prettier on all files. Github link
  • Remove unused babel-eslint dependency Github link
  • Upgrade to new package names for all rollup plugins. (@rollup/plugin-node-resolve instead of rollup-plugin-node-resolve) Github link
  • Remove file size impact workflow since it's broken. by @joeldenning in #879
  • Remove console.log in test by @joeldenning in #878

· One min read

Attendees: Joel Denning, Milan Kovacic, Jake Hayes

November 2023 Roadmap

  1. Release single-spa@6 as latest
  2. Consolidate and update the example projects

Meeting Notes

  • Open pull requests, pressing Github issues
  • Core team vacancy
    • Add Jake Hayes to the #core-team channel, but not officially a core team member
    • Joel will reach out to Ian about joining the core team.
  • Single-spa roadmap
  • Maintenance update/plan

Roadmap Brainstorm

  • Adding unit tests to existing projects
  • SystemJS -> ESM migration
  • create-single-spa update (
  • Release single-spa 6 as latest
  • Improve shared dependencies management
  • Autopublishes to npm
  • Server rendering enhancements?
  • Support for NextJS, NuxtJS, Remix, create-react-app, and other build tools
  • Consolidate example projects
  • Feature voting
  • Automated integration tests for popular frameworks
  • Update create-single-spa dependencies

· 2 min read

Please welcome the latest additions to the Single-Spa core team. These talented individuals bring fresh energy and a wealth of expertise and are poised to revitalize and expand the Single-Spa project.

Meet the Team

Artur Androsovych

Artur Androsovych is a Google Developer Expert in Angular and an open-source contributor who has been focusing on runtime performance and teaching teams about Angular internals for the past few years. He has maintained the single-spa-angular project for years, and we're excited for him to join the core team.

Roberto Mosca

Roberto is a Principal Software Engineer at TravelPerk (, where he is the go-to person for all things related to their frontend platform. With a full-stack background, he's got his hands on a variety of tech — from Python to NodeJS, React, Webpack... Before diving into the world of business travel, he was immersed in biomedical research as a bioinformatician. When he is not in front of a screen, you’ll find him swimming, cooking up some Italian delicacies, or tinkering with his Rubik’s cube-solving robots.

Milan Kovacic

Milan Kovacic is a seasoned software consultant with deep expertise in various development domains. On the frontend side, his work is marked by proficiency in React, TypeScript, and the integration of microfrontends. For backend solutions, he mostly relies on the .NET framework, C#—often utilizing microservices architecture. Additionally, Milan is experienced with cloud technologies, regularly working with platforms like AWS and Azure. Beyond traditional development, he places great emphasis on ensuring a smooth developer experience and promotes the use of automation and efficient DevOps practices to streamline development workflows.

These three new members will be joining current members Joel Denning, Carlos Filoteo, and Anthony Frehner to manage GitHub and Slack issues and actively develop new features. We’d also like to give special recognition to contributors from Qiankun for their extensive support over the years.

As part of this team update, we’ll also be creating a public roadmap, providing transparency about Single-Spa's future direction. To maintain transparency and encourage collaboration, we're establishing monthly meetings where the core team will discuss progress, challenges, and ideas. Meeting notes will be publicly available, ensuring that the community is well-informed and able to participate in our discussions.

So stay tuned and join us on this journey shaping the future of microfrontends.

· 2 min read

We are happy to announce that the single-spa core team is opening applications for two new members! As a core team member, you will help us maintain and guide the growing single-spa ecosystem by responding to Github and Slack issues, implementing new features, and helping to create the roadmap for the future of single-spa.

Our current core team consists of Joel Denning, Carlos Filoteo, and Anthony Frehner. We also thank Justin McMurdie and Bret Little for their valuable contributions during their time with the single-spa core team.

Single-spa owes its success to the people and companies who support it. If you want to contribute but aren’t able to join the core team, consider applying to be a maintainer. Maintainers are volunteers who receive Github write access to specific subprojects within the ecosystem. If you’re a manager at a company that uses single-spa, we encourage you to allow your developers to volunteer their time as maintainers or core team members so that the project can continue to grow and develop.

The single-spa core team and maintenance are unpaid volunteer positions. Looking ahead, if any core team members or maintainers are interested in new paid roles, Convex Cooperative (the company Joel works for) will be considering hiring new developers from the single-spa team. It’s important to state that Convex will not poach developers away from companies who allow their developers to help us maintain single-spa—our priority is nurturing the growth and development of the single-spa ecosystem.

If interested in applying to be a single-spa maintainer or core team member, please fill out the following Google Form before September 1, 2023: