npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@wapo-fusion/elex-cal-beta

v0.0.5

Published

## What?

Downloads

12

Readme

Fusion features as NPM modules (POC).

What?

This repo lays out a proof of concept for handling our cross team fusion features as separate npm modules in isolated git repositories

Why?

Coordination

Git history, Deployment scheduling, and code organization are all easier on smaller scales. Single monolithic repositories are hard to scale to many many developers.

Discoverability

Code reuse just for the sake of being "DRY" means that you spend more time looking for the getCookie utility than it would have taken you to write your own. Yes, we don't need a million different getCookie implementations, but getting a cookie is also not a closely guarded company secret, It's ok for teams to have their own utilities in locations where it make sense for their particular project. This benefit falls naturally from decoupling our repositories and managing them separately.

Explicit vs Accidental Code reuse.

This last point is related to the ones preceding it. We want to share code in an explicit and deliberate way instead of doing so accidentally. A good example would be sharing our design system. A bad example might be sharing a single Tracking or Analytics component between multiple teams with vastly different analytics requirements. We want our different teams to adhere to the same design priniclples across most projects and teams. We may not want every team to inherit the Analytics / Tracking requirements on normal articles. By separating our repositories we can isolate the things that we don't want to accidentally share and centralize the things we do want to share.

How?

This repo uses storybook as a means of component development. It mocks the fusion environment by mocking commonly used tools like useContent or Consumer. It comes with a build script that exports 2 files components and content. They contain components and content sources respectively. All users of this repo must do is place an index.js entriy point in both directories that exports (using named exports) the components or content sources. The plan then is that the fusion team will consume these npm modules and set them up appropriately within the wp-fusion project

Getting started

Development

Start story book.

Most development is intended to be done inside story book. This repository already contains a working example using a hypothetical "elections calendar" fusion feature. Simply use npm run story book in order to see it!.

A bit about directory structure

If you peer into the src folder you'll see a components folder where there is an index.js file as well as index.stories.js, the former containing our actual calendar component and the latter containing our storybook stories. If story book is running making changes to our calendar should be immediately reflected using storybook's hot reloading.

The possibilities are many here. The only requirement for compatibility with fusion is that an entry point exists (index.js) in both the components directory and the content-sources directory. Both of these files can export as many members as you like

Build and publish.

Once you have made some code changes and are ready for another release you'll need to build and publish your code.

npm run build

Then increment the version number in package.json to the appropriate version number (use semver!).

npm publish

You've now published a new version of both your features and your content sources. They can be imported in fusion in this manner:

// components/feature/elex/calendar.js
import { Calendar } from "@wapo-fusion/elex-cal-beta/components";

export default Calendar

// content/elex-calendar.js
import { calendar } from "@wapo-fusion/elext-cal-beta/content";

export default calendar