0.0.1 • Published 10 months ago

micro-front-end-template v0.0.1

Weekly downloads
-
License
ISC
Repository
-
Last release
10 months ago

Introduction

This project uses Module Federation to serve React components as a remote source to a consuming application. Each component to be served remotely is defined in the webpack config file and you can find an example in the Remotes section below.

There is a small app setup for local development and QA testing so that these components can run on their own release pipeline, without having to run them within boost.

Getting Started

Node

You will need Node version 12 or greater to run this application. The easiest way to do that, and to later switch versions, is to use nvm and install the LTS with nvm install --lts

This app is deployed on Node 14 LTS.

Installation

This project uses a private package called ekos-component-library which is stored in an Azure artifact feed. To make sure you can install this package, follow the instructions on this page to authenticate your machine.

Download dependencies by running npm i

Commands

  • npm start - runs the development server
  • npm run build:dev - creates a dev build
  • npm run build:qa - creates a qa build
  • npm run build:uat - creates a uat build
  • npm run build:prod - creates a production build
  • npm run serve - serves the production build on a local server
  • npm run prettier - runs prettier against all .js, .jsx, .ts, .tsx, .scss, and .css files
  • npm run eslint - runs prettier against all .js, .jsx, .ts, and .tsx files
  • npm run lint - runs lint check with eslint, stylelint, and prettier; synchronously
  • npm run typecheck - runs typescript compiler to check for errors
  • npm run test - runs jest tests
  • npm run test:watch - runs jest tests with watch and detectOpenHandles flags
  • npm run test:coverage - runs jest tests and collects coverage
  • npm run test:ci - runs jest tests and creates reports for consumption by Azure and SonarCloud

Dev Server

Run the development server:

npm start

Open http://localhost:4001 with your browser to see the result. Pages will auto-update as you edit the files. The port 4001 was chosen so it will not collide with other apps that typically run on 3000 or 3001.

If you would like to update the port so that you can run multiple projects at once, update the port in the webpack config file.

Remote components

To serve components as a module federation remote, they must be added to the webpack module federation plugin. Open webpack.config.js and find the plugin. There is an exposes list of components that will be served by remoteEntry.js. This list of components should look like this:

exposes: {
  './Example': path.resolve(
    __dirname,
    './src/components/example/Example'
  ),
},

Testing Locally

New components can be added as a Route in App.tsx which will allow you to test it out in a local app. This app will get deployed as a static site and can be access by dev or qa, but will not be used for anything other than hitting the url to get the remote components.

To test within another application, create a build and run the test server with npm run build:dev && npm run serve. This will allow another project, like Boost, to load a component from this project as a module federation remote. Set the remote url to http://localhost:4001 in the host application and set the public url environment variable in this project to localhost as well. Create a new route with the Federated Component and point it to this local url. You can then hit that url and see your remote component render inline with the app.

Components will be served at http://localhost:4001/remoteEntry.js so you can test whether they are being exported by hitting that url to see if you get the correct JS back.

Contributing Guide

All code should pass lint, typecheck, and test in order for a pull request to be merged. These checks will be performed in Azure DevOps as part of a pipeline when the pull request is opened.

Documentation

As much as possible, the code should be self-documenting using clear variable/function names and utilizing Typescript for type definitions.

JSDoc should be used for functions and class methods to provide a useful description. Arguments types should be defined using Typescript and functions should have an explicit return type.

You can also use the VSCode extension Document This + alt + ctrl and then d twice