To help you get started, we've collected the most common ways that mwp-core is being used within popular public projects.

meetup / meetup-web-platform / packages / mwp-core / src / renderers / server-render.jsx View on Github

const requestLanguage = request.getLanguage();

	return {
		apiUrl: API_ROUTE_PATH,
		baseUrl: host,
		basename: requestLanguage === 'en-US' ? '' : `/${requestLanguage}`, // basename is the 'base path' for the application - usually a localeCode
		enableServiceWorker,
		requestLanguage,
		supportedLangs: server.settings.app.supportedLangs,
		initialNow: new Date().getTime(),
		isProdApi: server.settings.app.api.isProd,
		isQL: parseMemberCookie(state).ql === 'true',
		memberId: parseMemberCookie(state).id, // deprecated, use member.id
		// the member cookie is not structured the same way as the member object returned from /member/self
		// be careful relying on it to have the same properties downstream
		member: parseMemberCookie(state),
		variants: getVariants(state),
		entryPath: url.pathname, // the path that the user entered the app on
		media: getMedia(userAgent, userAgentDevice),
		browserId: parseBrowserIdCookie(state),
		clientIp,
		siftSessionId: parseSiftSessionCookie(state),
		isBot: isBot(request.headers['user-agent']),
	};
};

View more ways to use mwp-core

Deprecated

Web Platform Components

This is the base platform for serving Meetup web apps including the public website and admin. It provides a Hapi webserver and a set of conventions for composing applications with React + Redux.

In general, application-specific code will live outside of this package.

• Public modules
• Releases
  • Development/Beta releases
  • Adding a new package

Public modules

• Analytics/tracking
• App configuration
• Auth plugin
• Rendering in consumer applications
• Routing module
• Language plugin for Hapi
• API proxy plugin for Hapi
• Click and Activity tracking
• API State module
  • 'Query': structuring data requests - GET/POST/PATCH/PUT/DELETE requests to REST API
• Redux store modules - browser and server

Releases

This package uses semver versioning to tag releases, although the patch version is determined exclusively by the Travis build number for pushes to main. Major and minor versions are hard-coded into the Makefile.

Manual pushes to main and PR merges to main will be built by Travis, and will kick off the yarn publish routine. The currently-published version of the package is shown on the repo homepage on GitHub in a badge at the top of the README.

Development/Beta releases

When developing a consumer application that requires changes to the platform code, you can release a beta version of the platform on npm by opening a PR in the meetup-web-platform repo. When it builds successfully, a new beta version will be added to the list of available npm versions. The generated version number is in the Travis build logs, which you can navigate to by clicking on 'Show all checks' in the box that says 'All checks have passed', and then getting the 'Details' of the Travis build.

At the bottom of the build log, there is a line that echos the GIT_TAG. If you click the disclosure arrow, the version number will be displayed, e.g. 0.5.177-beta.

You can then install this beta version into your consumer application with

> yarn add -W \
    mwp-api-state@ \
    mwp-app-render@ \
    mwp-app-server@ \
    mwp-config@ \
    mwp-core@ \
    mwp-i18n@ \
    mwp-router@ \
    mwp-store@ \
    mwp-toaster@

Each time you push a change to your meetup-web-platform PR, you'll need to re-install it with the new tag in your consumer application code.

The overall workflow is:

1. Open a PR for your meetup-web-platform branch
2. Wait for Travis to successfully build your branch (this can take 5+ minutes)
3. Get the version string from the build logs under GIT_TAG
4. Update the mwp-* (except mwp-cli) on your consumer application and test the changes
5. (if needed) Push changes to your meetup-web-platform branch
6. Repeat steps 2-3

Adding a new package

1. Create a new mwp-* directory in /packages/
2. Add a new package.json file in the new package
3. Add a line to .travis.yml before_install to create a .npmrc file that will enable NPM publishing
4. Increment the version number (a point release is usually okay since a new package is not a breaking change of existing packages)
5. Add a line to the CHANGELOG.md

If other MWP packages will depend on the new package, you'll need to first publish the package without updating dependencies in other packages, and then make a new release that updates the other packages with the new dependency - the dependency must exist in NPM before it can be specified as a dependency.