Security News
New Python Packaging Proposal Aims to Solve Phantom Dependency Problem with SBOMs
PEP 770 proposes adding SBOM support to Python packages to improve transparency and catch hidden non-Python dependencies that security tools often miss.
single-spa
Advanced tools
single-spa is a JavaScript framework for front-end microservices. It allows you to build and manage multiple microfrontends that can coexist and interoperate within a single web application. This enables teams to work independently on different parts of a web application, using different frameworks if necessary.
Registering Applications
This feature allows you to register multiple applications with single-spa. Each application can be loaded dynamically and activated based on the URL path.
const singleSpa = require('single-spa');
singleSpa.registerApplication({
name: 'app1',
app: () => System.import('app1'),
activeWhen: ['/app1'],
customProps: {}
});
singleSpa.start();
Mounting and Unmounting Applications
This feature allows you to manually mount and unmount applications, giving you fine-grained control over which applications are active at any given time.
const singleSpa = require('single-spa');
singleSpa.registerApplication({
name: 'app2',
app: () => System.import('app2'),
activeWhen: ['/app2'],
customProps: {}
});
singleSpa.start();
// Manually mount an application
singleSpa.mountRootParcel('app2', { domElement: document.getElementById('app2-container') });
// Manually unmount an application
singleSpa.unmountRootParcel('app2');
Custom Events
This feature allows you to dispatch and listen for custom events, enabling communication between different microfrontends.
const singleSpa = require('single-spa');
singleSpa.registerApplication({
name: 'app3',
app: () => System.import('app3'),
activeWhen: ['/app3'],
customProps: {}
});
singleSpa.start();
// Dispatch a custom event
window.dispatchEvent(new CustomEvent('custom-event', { detail: { someData: 'data' } }));
// Listen for a custom event
window.addEventListener('custom-event', (event) => {
console.log(event.detail.someData);
});
qiankun is a micro-frontend framework based on single-spa. It provides additional features like sandboxing and lifecycle hooks, making it easier to manage microfrontends in complex applications.
mooa is a micro-frontend framework inspired by single-spa. It focuses on Angular applications and provides a simpler API for integrating multiple Angular microfrontends.
icestark is a micro-frontend framework developed by Alibaba. It offers a set of tools and conventions for building and managing microfrontends, with a focus on React and Vue applications.
Multiple applications all lazily loaded and mounted/unmounted in the same single page application (SPA). The apps can be deployed independently to your web server of choice, lazy-loaded onto the page independently, and nested. Single-spa also allows for service oriented javascript, where a "service" (a shared es6 module) is a singleton that each app can call, without resorting to shared libraries that can be out of sync across apps.
In this context, an application is an html document that pulls in JS, CSS, and more HTML. This means that many pre-existing applications do not need to change at all in order to work with single-spa. You just need to add a configuration file on top of your existing SPA.
Single-spa works in Chrome, Firefox, Safari, IE11, and Edge.
A demo is live on surge.sh. Don't be turned off by the lack of styling -- I'll be fixing that soon. It's based on the code in the examples repository.
The hope here is that "one SPA to rule them all" will help scale teams and organizations that have complex apps -- this is done by making it easier to split code and then deploy it independently. To explain why single SPA is advantageous, consider the following disadvantages of a multiple SPA approach:
In general, the process is to create a root app which imports single-spa and declares child applications by calling singleSpa.declareChildApplication(...)
. Each child application starts out as just a single-spa.config.js file, with the rest of the app (the html document, the js, the css, etc) being lazy loaded later on. As the app is being loaded, mounted, unmounted, etc., lifecycle functions are called to allow customized behavior. SSPA plugins are written to standardize the lifecycle functions for popular technologies like angular, jspm, react, webpack, etc.
Example:
// root-app.html
<html>
<head>
<script src="/jspm_packages/system.src.js"></script>
<script src="/config.js"></script>
<script>
System.import('/root-app.js');
</script>
</head>
</html>
// root-app.js
import { declareChildApplication } from "single-spa";
declareChildApplication('/apps/myApp/single-spa.config.js', () => window.location.pathname.startsWith('/myApp'));
// apps/myApp/single-spa.config.js
export const publicRoot = '/apps/the-directory-my-app-is-in'; //the path on the web server to the directory the app is in.
export const pathToIndex = 'index.html'; //This is a relative url (based on publicRoot) to the html document that bootstraps your app
export const lifecycles = []; //put any plugins (i.e., for jspm or angular) here
single-spa-jspm is an actively maintained project that eases the burden of configuring jspm apps. To use it, run the following in your root app's directory
jspm install npm:single-spa-jspm
and then add the following to the jspm app's single-spa.config.js:
import { defaultJspmApp } from "single-spa-jspm";
export const lifecycles = [...(any other plugins)..., defaultJspmApp()]
Thus far it seems that it's best to put your JSPM lifecycles at the end of the array.
So far, webpack has not required any special configuration to work in an SSPA environment. It works out of the box! So no need to add a "lifecycle" for webpack in your single-spa.config.js file.
One thing to watch out for, though, is to make sure that any urls in your webpack config are relative urls. For example, use publicPath: 'build/'
instead of publicPath: '/build/'
single-spa-react is an actively maintained project that eases the burden of configuring react apps. To use it, run the following in your root app's directory
jspm install npm:single-spa-react
and then add the following to your single-spa.config.js:
import { defaultReactApp } from "single-spa-react";
export const publicRoot = '...';
export const pathToIndex = 'index.html';
const reactApp = defaultReactApp({
rootElementGetter: function() {
return document.querySelector('#root-react-element');
},
mountApp: function() {
return ReactDOM.render(<MyApp/>, document.getElementById('root-react-element');
},
ReactDOMGetter: function() { //only needed if the ReactDOM object is not leaked as a global
return window.app.ReactDOM; //or however you want to reference ReactDOM
}
});
export const lifecycles = [reactApp, ...(any other plugins)...];
single-spa-angular1 is an actively maintained project that eases the burden of configuring Angular apps. To use it, run the following in your root app's directory
jspm install npm:single-spa-angular1
and then add the following to your single-spa.config.js
import { defaultAngular1App } from "single-spa-angular1";
export const publicRoot = '....'; //the path on the web server to the directory the app is in
const angular1App = defaultAngular1App({
publicRoot: publicRoot,
rootAngularModule: '[name of your root angular module]',
rootElementGetter: () => document.querySelector('#app-root') //or some other way of getting the root element
});
export const lifecycles = [...(any other plugins)..., angular1App]
single-spa-globals is an actively maintained project that eases the burden of configuring apps that leak globals. To use it, run the following in your root app's directory
jspm install npm:single-spa-globals
and then add the following to your single-spa.config.js
import { appWithGlobals } from "single-spa-globals";
export const publicRoot = '....';
export const pathToIndex = 'index.html';
export const lifecycles = [...(any other plugins)..., appWithGlobals(['app1', 'globalVar1', 'anotherGlobal'])]
react-router apps usually require no more configuration than plain old react apps (see above for how to do that). The only thing that may need to change in your app is the basename
that is used when creating your history object. But that only needs to happen if you're using URLs to determine which app is active at any given time.
For example, you may have to do something like this:
import history from "history";
const history = history.useBasename(history.createHistory)({
basename: '/path-that-is-active-when-this-app-is-active'
})
There is also an examples repository that shows several apps working great in a single-spa environment. The following files are a good place to start:
Also note that it requires that as of 11/1/15, the root app that loads all other apps must be written with JSPM. The goal is to move away from that towards the whatwg/loader standard, probably polyfilled with the es6-module-loader.
<base>
tag, which means that apps should not control it. single-spa-angular1 makes it possible for angular to still work (even with History API pretty urls!) without the angular app putting a <base>
tag in the app's index.html.FAQs
The router for easy microfrontends
We found that single-spa demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
PEP 770 proposes adding SBOM support to Python packages to improve transparency and catch hidden non-Python dependencies that security tools often miss.
Security News
Socket CEO Feross Aboukhadijeh discusses open source security challenges, including zero-day attacks and supply chain risks, on the Cyber Security Council podcast.
Security News
Research
Socket researchers uncover how threat actors weaponize Out-of-Band Application Security Testing (OAST) techniques across the npm, PyPI, and RubyGems ecosystems to exfiltrate sensitive data.