DEV Community: Robert Wagner

Top 5 Web Developer Tools for 2023

Robert Wagner — Thu, 08 Dec 2022 13:02:40 +0000

When was the last time you updated your web development tools?

I don't know about you, but when I find tools I like to use for web development, I tend to stick with them for many, many years. This isn't necessarily a bad thing, but in the past year or two a lot of new and interesting tools have dropped, and I am loving using them.

I think, at this point, most of us know about VSCode, and while I do use it daily, I am not going to be highlighting it in this post. So, without further ado, let's jump into a list of my top five developer tools for working on and consuming the web in 2023 and beyond.

1. Arc

It has been a long time since I got excited about a new browser. It seems like most "new" browsers are often a Chrome clone that has been reskinned and maybe has a few extra features. Chrome is a great browser, don't get me wrong, and browsers like Brave have made Chromium even cooler, but The Browser Company has dramatically changed the game with their new browser: Arc.

Arc moves your tabs to the left side and introduces the concept of Spaces, which allows you to organize your tabs by category. For example, I have Spaces for personal, work, and podcasting. There is also an ever-present favorites bar for sites you visit extremely frequently.

Perhaps the best feature, of their reimagination of tabs, is you can set the tabs to auto close. For tab hoarders like me, this is a game changer, and keeps my huge tabs collection in check.

Arc also has great keyboard support, with a command palette-like interface when you press CMD + T. This maps to your existing muscle memory of opening a new tab, but allows you to perform multiple different actions, instead of just opening a tab.

There are many other features and quality-of-life improvements baked into Arc, so give it a try for yourself and see what you think!

2. Warp

Warp touts itself as "The terminal for the 21st century", and I think that's a pretty fair statement. It adds loads of features that most other terminal apps do not offer, and it's written in Rust, making it blazing fast, so it easily outperforms Electron-based terminals.

One of the coolest features of Warp is its AI Search. You may have been hearing a lot about GPT-3 and OpenAI Chat recently, and how powerful it is. Well, Warp uses the same amazing GPT-3 technology to power its AI search, which means searching things like delete git branch will suggest git branch -d branch_name, so finding the command you need is a breeze.

Warp has also reimagined how your output is displayed. Instead of a huge wall of text, your commands and their output are grouped into blocks. This allows you to easily navigate through them, and share them with your team for easier debugging.

Terminal sharing is coming soon, so you can share a permalink to your terminal with your team, and they can view it in real-time. Soon documentation will be supported inside Warp as well, so there will be no need to navigate to an external wiki or docs site, and instead, you can view the docs directly inline.

To learn more about Warp, check out our
podcast episode with Warp's founder, Zach Lloyd.

3. Zed

I just recently got my invite from Zed, so I have not had a ton of time to play with it, but the concept seems really cool, so I wanted to make sure to highlight it here. Zed tries hard to remove anything you don't need, so the
window appears very bare bones. This eliminates distractions and gives you more space to work.

The real selling point of Zed, however, is its collaboration features. You can invite any of your contacts to view your session and code alongside you, which is much easier and more productive than trying to screen share via Zoom. It allows true collaboration on the same file, at the same time.

4. GitHub Desktop

This one flies under the radar and is very underrated, in my opinion. There are a lot of very powerful tools for git built around power users and handling complex workflows, but if you use GitHub and you want something simple and intuitive to push and pull code, GitHub Desktop is a great tool.

One of my favorite things is having a button to open a new pull request from my branch. It takes out the unnecessary step of needing to push, then open GitHub and create a PR. It seems like a small thing, but I find it incredibly useful.

5. Fig

Your browser doesn't support the video tag.

Another player, new to the terminal space, is Fig. Fig adds IDE-style autocomplete to your existing terminal. It works with the three most popular shells: bash, zsh, and fish and has integrations with various terminal apps and IDEs. It is very helpful when trying to remember commands or if you
want to save keystrokes!

Wrap-up

These, in my opinion, are the top 5 web developer tools people should be checking out in 2023 and beyond. If there is a developer tool you think should have been on this list, let us know on Twitter!
(@whiskeywebfm)

Top 5 JavaScript Podcasts for 2023

Robert Wagner — Wed, 30 Nov 2022 21:57:47 +0000

Which JavaScript podcasts are the hottest?

Although podcasts are not a new thing, they have exploded in popularity over the last several years. Likewise, JavaScript is also not new, but has continued to grow exponentially and is used in all sorts of ways from building user interfaces to writing serverless functions.

It is no surprise that there are also a growing number of podcasts centering around web development and JavaScript, but which ones should you listen to? We'll break down the top five JavaScript podcasts to listen to, to stay up to date on the latest JavaScript trends.

1. Syntax

One of the most popular, and tastiest web development podcasts out there is Syntax by Scott Tolinski and Wes Bos. They keep things lighthearted and fun with games like Stump'd where they do random JavaScript interview questions and try to stump one another.

They release three episodes a week of various formats, a short "Hasty Treat", a longer "Tasty Treat", and their relatively new Supper Club where they interview guests from the developer community.

2. Shop Talk Show

If you have been around the web development scene for a while, you have probably heard of CSS-Tricks and/or CodePen, and if you have, you are likely also familiar with their founder, Chris Coyier. He and Dave Rupert release episodes of Shop Talk weekly for the Shopamaniacs and cover a wide range of topics from JavaScript and CSS to parenting and hot topics of the day.

3. JS Party

JS Party has had many hosts over the years and countless guests all doing deep dives into various web development topics. From new browser features coming out, to fancy ways to do page layouts with one line of CSS, to the latest JavaScript frameworks, they get deep into the technical details of their topics to help keep you up to date.

4. Whiskey Web and Whatnot

We may be a bit biased here, but we think our podcast
Whiskey Web and Whatnot has a great
format as both an informative JavaScript podcast and an entertaining fireside chat with some of your favorite devs, like the aforementioned Wes Bos and Chris Coyier, as well as other prominent developers like Charlie Gerard, Kelly Vaughn, and Kent C. Dodds.

If you're looking for something a little less technical, find an episode that sounds interesting, grab a glass, and have a drink with us.

5. Front End Happy Hour

Front End Happy Hour is another somewhat less formal option featuring a panel of Software Engineers from Netflix, Twitch, and Atlassian talking over drinks about Frontend, JavaScript, and career development.

They have lots of guests from the Netflix engineering team, so it gives you a peek into how one of the hottest tech companies is approaching their web apps. They also talk about things such as job hunting, interview prep, and dealing with burnout.

Wrap-up

We think these are the top 5 JavaScript podcasts currently, but new podcasts are released all the time and this is not an exhaustive list. If we missed one of your favorites, let us know on Twitter!
(@whiskeywebfm)

5 Tips to Improve Your Terminal Experience

Robert Wagner — Thu, 26 May 2022 12:59:17 +0000

Working in software, we know the stereotypical terminals shown in movie scenes - with green text whizzing through black backgrounds as a hacker furiously slings commands from memory onto an eight inch screen - is far from the reality of today's development.

While our day-to-day development process might not appear as exciting and action-packed as the silver screen renditions, as software developers, we do have a lot of great options to streamline our workflows by improving the style and functionality of our terminals.

Fish

One of the biggest improvements to my experience in the terminal was from switching from bash to fish. Fish upgrades your terminal with features like autosuggestions, that remember commands you have run before and try to auto complete them for you, and automatically generates auto completes for other utilities by parsing their man pages, neat!

Starship

Starship is a cross-shell prompt that is blazing-fast, and infinitely customizable. It is built in Rust, which gives it best-in-class speed and safety, to make your prompt as quick and reliable as possible. Out of the box it shows you pertinent information like what git branch you are on, what version of CLI tools you are running (e.g. node, Rust, etc), how long commands took to run, and so much more!

MonoLisa

Yes, this font costs money, and yes it is worth spending money on. There are a lot of nice free fonts out there, and I personally used Input before, but there is just something special about MonoLisa that cannot be put into words. It just feels clean and extremely legible. Their website says it was designed "to improve developers' productivity and reduce fatigue" and I think they nailed it!

Hyper

The built in terminal on Mac is decent, and has been getting some updates, but it tends to lag behind alternatives in terms of features. iTerm is another popular option, and new players to the space like Warp promise all kinds of new and exciting features.

However, my current gold standard for terminals is Hyper. I have been using it for many years and it was built by the folks at Vercel, who you may have heard of.

asdf

If you have worked on multiple different projects, throughout your career, odds are you have encountered a need to switch node, ruby, etc. versions depending on the project. There are several independent tools that exist for managing versions of these tools like nvm and rvm but I have recently been opting more for an all-in-one solution asdf.

asdf supports auto switching versions of tools as you change directories in your terminal, so if you create a .tool-versions file and specify the versions there, you can magically use the correct versions for every project, as soon as you cd into that directory! 🎉

Launching Electron Apps From the Browser

Robert Wagner — Wed, 10 Feb 2021 01:09:01 +0000

Everyone has probably encountered this situation at least a few times in their lifetime:

You're browsing the web and come across a file or link you want to open in an app on your computer.
Your browser will prompt you to make sure it's okay with a nice message like this:

This is incredibly useful, and allows users to have a seamless workflow of going straight to your app.

Electron app -> browser

We have been working tirelessly on new features for Swach, and one of those new features was the ability to share palettes with other users and view them online.
The sharing aspect was trivial. We used Electron's shell module which provides an openExternal
method that we used to generate a link with query params to pass the palette data to swach.io.

Browser -> Electron app

Going the other direction, with deep links, proved much harder, however. Electron does support using deep links and custom protocols out of the box with setAsDefaultProtocolClient, but opening these custom protocol links requires a much different setup for different platforms.

macOS

On macOS there is a special open-url event that is supported, which makes things fairly straightforward.
We can set our app as the default protocol client, and then use open-url to handle importing our data.

Note: You can replace custom with whatever you want to name your custom protocol.



let deeplinkingUrl;

app.setAsDefaultProtocolClient('custom');

app.on('open-url', function (event, url) {
  event.preventDefault();
  deeplinkingUrl = url;
});

We will also need to add these custom protocols to our plist. If you are using electron-forge or electron-builder, you can add this to your config.

electron-forge



packagerConfig: {
  protocols: [
    {
      protocol: 'custom',
      name: 'custom',
      schemes: 'custom'
    }
  ]
}

electron-builder



"build": {
  "protocols": [
    {
      "name": "custom",
      "schemes": [
        "custom"
      ]
    }
  ]
}

Windows

On Windows, the open-url event is not supported, and instead Electron will try to open a new instance of your application.
We will have to catch this and focus our existing application instead. We also have to modify setAsDefaultProtocolClient to support running in dev mode in Windows.



if (isDev && process.platform === 'win32') {
  // Set the path of electron.exe and your app.
  // These two additional parameters are only available on windows.
  // Setting this is required to get this working in dev mode.
  app.setAsDefaultProtocolClient('custom', process.execPath, [
    resolve(process.argv[1])
  ]);
} else {
  app.setAsDefaultProtocolClient('custom');
}

// Force single application instance
const gotTheLock = app.requestSingleInstanceLock();

if (!gotTheLock) {
  app.quit();
  return;
} else {
  app.on('second-instance', (e, argv) => {
    if (process.platform !== 'darwin') {
      // Find the arg that is our custom protocol url and store it
      deeplinkingUrl = argv.find((arg) => arg.startsWith('custom://'));
    }

    if (myWindow) {
      if (myWindow.isMinimized()) myWindow.restore();
      myWindow.focus();
    }
  });
}

Final Result

Our final result is something like this:



let deeplinkingUrl;

if (isDev && process.platform === 'win32') {
  // Set the path of electron.exe and your app.
  // These two additional parameters are only available on windows.
  // Setting this is required to get this working in dev mode.
  app.setAsDefaultProtocolClient('custom', process.execPath, [
    resolve(process.argv[1])
  ]);
} else {
  app.setAsDefaultProtocolClient('custom');
}

app.on('open-url', function (event, url) {
  event.preventDefault();
  deeplinkingUrl = url;
});

// Force single application instance
const gotTheLock = app.requestSingleInstanceLock();

if (!gotTheLock) {
  app.quit();
  return;
} else {
  app.on('second-instance', (e, argv) => {
    if (process.platform !== 'darwin') {
      // Find the arg that is our custom protocol url and store it
      deeplinkingUrl = argv.find((arg) => arg.startsWith('custom://'));
    }

    if (myWindow) {
      if (myWindow.isMinimized()) myWindow.restore();
      myWindow.focus();
    }
  });
}

For a good example of supporting deep linking / custom protocols on both macOS and Windows, check out this example app.

Tailwind UI Dropdowns with Ember

Robert Wagner — Fri, 29 Jan 2021 14:30:25 +0000

Tailwind CSS has exploded in popularity recently, and so has their paid set of UI components, Tailwind UI.
They have a lot of great components, most of which you can copy and paste into your project and they will "just work", but whenever an example requires some JavaScript, things get a little more complex.

For example, one of the Tailwind UI dropdown component examples is:

<!-- This example requires Tailwind CSS v2.0+ -->
<div class="relative inline-block text-left">
  <div>
    <button
      class="bg-gray-100 rounded-full flex items-center text-gray-400 hover:text-gray-600 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-offset-gray-100 focus:ring-indigo-500"
      id="options-menu"
      aria-haspopup="true"
      aria-expanded="true"
    >
      <span class="sr-only">Open options</span>
      <!-- Heroicon name: dots-vertical -->
      <svg
        class="h-5 w-5"
        xmlns="http://www.w3.org/2000/svg"
        viewBox="0 0 20 20"
        fill="currentColor"
        aria-hidden="true"
      >
        <path
          d="M10 6a2 2 0 110-4 2 2 0 010 4zM10 12a2 2 0 110-4 2 2 0 010 4zM10 18a2 2 0 110-4 2 2 0 010 4z"
        />
      </svg>
    </button>
  </div>

  <!--
    Dropdown panel, show/hide based on dropdown state.

    Entering: "transition ease-out duration-100"
      From: "transform opacity-0 scale-95"
      To: "transform opacity-100 scale-100"
    Leaving: "transition ease-in duration-75"
      From: "transform opacity-100 scale-100"
      To: "transform opacity-0 scale-95"
  -->
  <div
    class="origin-top-right absolute right-0 mt-2 w-56 rounded-md shadow-lg bg-white ring-1 ring-black ring-opacity-5"
  >
    <div
      class="py-1"
      role="menu"
      aria-orientation="vertical"
      aria-labelledby="options-menu"
    >
      <a
        href="#"
        class="block px-4 py-2 text-sm text-gray-700 hover:bg-gray-100 hover:text-gray-900"
        role="menuitem"
        >Account settings</a
      >
      <a
        href="#"
        class="block px-4 py-2 text-sm text-gray-700 hover:bg-gray-100 hover:text-gray-900"
        role="menuitem"
        >Support</a
      >
      <a
        href="#"
        class="block px-4 py-2 text-sm text-gray-700 hover:bg-gray-100 hover:text-gray-900"
        role="menuitem"
        >License</a
      >
      <form method="POST" action="#">
        <button
          type="submit"
          class="block w-full text-left px-4 py-2 text-sm text-gray-700 hover:bg-gray-100 hover:text-gray-900 focus:outline-none focus:bg-gray-100 focus:text-gray-900"
          role="menuitem"
        >
          Sign out
        </button>
      </form>
    </div>
  </div>
</div>

Notice this part in the middle about the enter/leave transitions:

<!--
    Dropdown panel, show/hide based on dropdown state.

    Entering: "transition ease-out duration-100"
      From: "transform opacity-0 scale-95"
      To: "transform opacity-100 scale-100"
    Leaving: "transition ease-in duration-75"
      From: "transform opacity-100 scale-100"
      To: "transform opacity-0 scale-95"
  -->

So not only do we need to support transitions on enter/leave, but each transition needs to support a from and to state.

I did some digging and found a framework agnostic solution
el-transition, and was about to use it, but then I discovered an Ember specific solution, which fit my needs better, since my app was using Ember.

The ember-css-transitions addon seemed to fit my use case perfectly. It ships a css-transition modifier that supports all the enter/leave and to/from states we needed.

The end result in Ember was something like:

<div class="relative inline-block text-left">
  <button
    class="px-1 rounded transition-colors {{
      if (and this.isShown @showBackground) "bg-main"
    }}"
    type="button"
    {{on "click" (stop-propagation (set this "isShown" (not this.isShown)))}}
    {{on-click-outside
      (set this "isShown" false)
      eventType="mousedown"
      exceptSelector=".options-menu *"
    }}
  >
    {{yield to="trigger"}}
  </button>

  {{#if this.isShown}}
    <div
      class="options-menu absolute bg-menu mt-2 p-2 origin-top-{{
        this.position
      }} {{
        this.position
      }}-0 ring-1 ring-main rounded-md shadow-lg text-menu-text w-44 z-50"
      {{css-transition
        enterClass="transform opacity-0 scale-95"
        enterActiveClass="transition ease-out duration-100"
        enterToClass="transform opacity-100 scale-100"
        leaveClass="transform opacity-100 scale-100"
        leaveActiveClass="transition ease-in duration-75"
        leaveToClass="transform opacity-0 scale-95"
      }}
      {{on "click" (stop-propagation (set this "isShown" false))}}
    >
      {{yield to="content"}}
    </div>
  {{/if}}
</div>

This applies all the transitions correctly, and gets us up and running with a Tailwind UI dropdown! 🎉 You may also have noticed the on-click-outside modifier and the Ember Named Blocks we are using here. More posts to follow going into more detail on those, but in the meantime hopefully this helps someone with transitions!

Releasing JavaScript Libraries with release-it

Robert Wagner — Tue, 18 Aug 2020 21:48:16 +0000

Originally published at shipshape.io

We maintain many open source projects at Ship Shape, and are constantly looking for better ways to handle processes like testing and linting, CI,
code coverage metrics, live previews etc., but one of the most ubiquitous needs across all of our packages is a consistent release pipeline.
Until recently, we didn't have a real set standard. We would use npm version and npm publish directly in some places, we would manually
push tags with git push --tags, and we were doing every step of the release pretty manually.

Once we discovered release-it, we were able to finally have a standard way of doing all the manual release bits in one easy command.
It allows us to bump the package version, generate a changelog, commit, tag, push commits, push tags, release on GitHub and release on npm all with a nice step-by-step CLI command.

To simplify the setup process even further, we have been using create-rwjblue-release-it-setup by the incomparable @rwjblue. Which does the following:

Adds release-it config to package.json
Installs required dependencies
Adds a CHANGELOG.md
Adds a RELEASE.md
Updates your repository's labels with rwjblue's "go to" defaults

This gets us up and running with release-it in a single command:

# in a yarn repo
yarn create rwjblue-release-it-setup

# in an npm repo
npm init rwjblue-release-it-setup

We are then up and running with release-it and are ready to release our packages! There are a lot of config options for release-it, if you have more custom needs, but
this should handle the basic case. Enjoy releasing your packages!

Signing Electron Apps with GitHub Actions

Robert Wagner — Sat, 18 Apr 2020 16:53:29 +0000

Originally published at shipshape.io

We've been working hard over the past many months, at Ship Shape, on a cross platform menubar color management app called Swach, and as part of that work, we had a need to sign our app for both MacOS and Windows. There are many existing articles on doing this with Travis or Appveyor, but the documentation for using GitHub actions is lacking, so we wanted to quickly share what we learned.

MacOS

Getting your certificate from Apple

You will need an Apple developer account to generate a certificate. You can sign up at https://developer.apple.com/programs/.

Once you have a developer account, you can go to your account and click
Certificates, Identifiers, and Profiles to manage your certificates. Click the plus button to add a new certificate.

At the time of writing, there are 9 types of certificates, but we are only interested in two. You will want to generate both the Developer ID Installer, and Developer ID Application certificates, as both are needed to sign the application and installer for distribution outside the app store.

Adding your certificate to GitHub

Once you have your certificates from Apple, you'll want to export them as a .p12, which we will then copy the contents of to save to GitHub as a secret.

base64 -w 0 path/to/your/certificate.p12

You will then want to copy your certificate output into a secret named CERTIFICATE_OSX_APPLICATION, as well as the password you set for the certificate to CERTIFICATE_PASSWORD.

Once the secrets are added, we need to write a script to get them into our keychain.

add-osx-cert.sh

#!/usr/bin/env sh

KEY_CHAIN=build.keychain
CERTIFICATE_P12=certificate.p12

# Recreate the certificate from the secure environment variable
echo $CERTIFICATE_OSX_APPLICATION | base64 --decode > $CERTIFICATE_P12

#create a keychain
security create-keychain -p actions $KEY_CHAIN

# Make the keychain the default so identities are found
security default-keychain -s $KEY_CHAIN

# Unlock the keychain
security unlock-keychain -p actions $KEY_CHAIN

security import $CERTIFICATE_P12 -k $KEY_CHAIN -P $CERTIFICATE_PASSWORD -T /usr/bin/codesign;

security set-key-partition-list -S apple-tool:,apple: -s -k actions $KEY_CHAIN

# remove certs
rm -fr *.p12

Calling the script in GitHub actions

You'll want to create a step in your actions something like this:

- name: Add MacOS certs
  if: matrix.os == 'macos-latest' && startsWith(github.ref, 'refs/tags/')
  run: chmod +x add-osx-cert.sh && ./add-osx-cert.sh
  env:
    CERTIFICATE_OSX_APPLICATION: ${{ secrets.CERTIFICATE_OSX_APPLICATION }}
    CERTIFICATE_PASSWORD: ${{ secrets.CERTIFICATE_PASSWORD }}

This will call the scripts when you are running on macos-latest and add the certs as env variables.

Notarizing your MacOS app

Apple now requires notarizing your MacOS apps as well. We use electron-forge for building our apps, which allows for notarizing as well, and our config looks like this:

packagerConfig: {
  asar: true,
  darwinDarkModeSupport: 'true',
  icon: 'electron-app/resources/icon',
  name: 'Your app name',
  osxSign: {
    entitlements: 'electron-app/src/entitlements.plist',
    'entitlements-inherit': 'electron-app/src/entitlements.plist',
    'gatekeeper-assess': false,
    hardenedRuntime: true,
    identity: 'Developer ID Application: YOUR NAME HERE (YOUR ID HERE)'
  },
  osxNotarize: {
    appleId: process.env['APPLE_ID'],
    appleIdPassword: process.env['APPLE_ID_PASSWORD']
  },
  packageManager: 'yarn'
},

You'll notice the osxNotarize section which essentially just requires you to set more GitHub secrets containing your APPLE_ID and APPLE_ID_PASSWORD to be used for notarizing.

Entitlements and other settings

We found that additional configuration was needed to get our application running as more than just a blank screen. We needed entitlements, as well as hardenedRuntime and gatekeeper-assess, but these settings will vary depending on your app. The entitlements.plist that we are using is:

entitlements.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.security.cs.allow-jit</key>
    <true/>
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
    <key>com.apple.security.cs.disable-executable-page-protection</key>
    <true/>
    <key>com.apple.security.automation.apple-events</key>
    <true/>
  </dict>
</plist>

That should be all you need for MacOS signing and notarizing via GitHub actions, but please let us know if you encountered any issues!

Windows

As with MacOS, Windows applications must also be signed, however Microsoft does not handle certificates in house, so you will need to get a third party certificate to use for signing. We got our certificate from GoDaddy, but see here for some alternative choices.

Once you get your certificate file, you'll need to output it to .pfx and then we will copy the output of that into a GitHub secret called CERTIFICATE_WINDOWS_PFX.

base64.exe -w 0 <your-certificate-name>.pfx

We will also need to add the password for the cert as a WINDOWS_PFX_PASSWORD GitHub secret.

We'll then add a step to our GitHub actions of the following:

- name: Add Windows certificate
        if: matrix.os == 'windows-latest' && startsWith(github.ref, 'refs/tags/')
        id: write_file
        uses: timheuer/base64-to-file@v1
        with:
          fileName: 'win-certificate.pfx'
          encodedString: ${{ secrets.CERTIFICATE_WINDOWS_PFX }}

This will copy the base64 output to a file to be used by the Windows signing process.

Electron Forge allows you to specify the Windows certificate file and password in the config for the Windows Squirrel maker, so once the file has been created you should just need to add the following to your config.forge.js.

makers: [
  {
    name: '@electron-forge/maker-squirrel',
    config: {
      name: 'Your app name',
      certificateFile: process.env['WINDOWS_PFX_FILE'],
      certificatePassword: process.env['WINDOWS_PFX_PASSWORD']
    }
  }
]

That should be all the setup necessary to get your Windows certificates up and running!

Building the application

Once your certificates are all setup, you should be ready to build your application. For completeness, here is our entire workflow file for GitHub actions, which includes adding all the certs, signing, and building the project.

It will only run tests unless a new tag is pushed. When a new tag is pushed, it will build on MacOS, Windows, and Ubuntu, and push all of those release assets to GitHub.

name: Package and Release

on:
  pull_request: {}
  push:
    branches:
      - master
    tags:
      - v*

jobs:
  test:
    name: Lint and Test
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v1
      - name: Use node 12.x
        uses: actions/setup-node@v1
        with:
          node-version: '12.x'
      - name: Yarn install
        run: yarn install-deps
      - name: Lint JS
        run: yarn lint:js
      - name: Lint HBS
        run: yarn lint:hbs
      - name: Get xvfb
        run: sudo apt-get install xvfb
      - name: Test
        run: xvfb-run --auto-servernum yarn test
  build:
    name: Build (${{ matrix.os }})
    if: startsWith(github.ref, 'refs/tags/')
    needs: test
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [macos-latest, ubuntu-latest, windows-latest]
    steps:
      - name: Checkout
        uses: actions/checkout@v1
      - name: Use node 12.x
        uses: actions/setup-node@v1
        with:
          node-version: '12.x'
      - name: Yarn install
        run: yarn install-deps
      - name: Add MacOS certs
        if: matrix.os == 'macos-latest' && startsWith(github.ref, 'refs/tags/')
        run: chmod +x add-osx-cert.sh && ./add-osx-cert.sh
        env:
          CERTIFICATE_OSX_APPLICATION: ${{ secrets.CERTIFICATE_OSX_APPLICATION }}
          CERTIFICATE_PASSWORD: ${{ secrets.CERTIFICATE_PASSWORD }}
      - name: Add Windows certificate
        if: matrix.os == 'windows-latest' && startsWith(github.ref, 'refs/tags/')
        id: write_file
        uses: timheuer/base64-to-file@v1
        with:
          fileName: 'win-certificate.pfx'
          encodedString: ${{ secrets.CERTIFICATE_WINDOWS_PFX }}
      # - name: Setup flatpak
      #   if: matrix.os == 'ubuntu-latest' && startsWith(github.ref, 'refs/tags/')
      #   run: sudo apt install flatpak flatpak-builder elfutils
      - name: Make
        if: startsWith(github.ref, 'refs/tags/')
        run: yarn make
        env:
          APPLE_ID: ${{ secrets.APPLE_ID }}
          APPLE_ID_PASSWORD: ${{ secrets.APPLE_ID_PASSWORD }}
          WINDOWS_PFX_FILE: ${{ steps.write_file.outputs.filePath }}
          WINDOWS_PFX_PASSWORD: ${{ secrets.WINDOWS_PFX_PASSWORD }}
      - name: Release
        uses: softprops/action-gh-release@v1
        if: startsWith(github.ref, 'refs/tags/')
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          files: |
            electron-app/out/**/*.deb
            electron-app/out/**/*.dmg
            electron-app/out/**/*Setup.exe
            electron-app/out/**/*.rpm
            electron-app/out/**/*.zip

Some of this is specific to our needs for Swach, and specific to both ember-electron and electron-forge usage, but most of it is generally applicable to any Electron app builds, so hopefully you can tweak it to work with whatever your setup may be!

Interested in building your own cross platform app? Ship Shape has extensive experience with Electron apps and progressive web apps.
Get help from the cross platform app experts! Contact us. We would love to work with you!

Converting a Webpack Build to Rollup

Robert Wagner — Mon, 18 Nov 2019 17:09:30 +0000

Originally published at shipshape.io

When we initially started on refreshing Shepherd, we wanted to modernize
the build process, and decided to switch from gulp to webpack. This worked well, and was a
step in the right direction, but with all the buzz around rollup 1.0, we decided to give it a try.

In some cases, things were a simple 1:1 conversion from a webpack plugin to a rollup plugin, but other things were much less straightforward.
We'll go through each conversion, step by step here, in the hopes that it will be helpful to others who may want to take rollup for a spin. If you just want
to see the entire webpack config and the entire rollup config, you can skip to the bottom and compare them yourself.

Linting
Local Development
Styles
Transpilation/Minification
Config Files
Summary

Linting

eslint-loader -> rollup-plugin-eslint

ESLint is a linting tool for JavaScript, that allows us to enforce code style for all of our JS. We typically use it
in all our projects and we are used to it running automatically, while serving or building, since this is baked into
Ember.js, so naturally we wanted to get this same behavior with rollup.

We used eslint-loader with webpack, and passed all JS through it,
excluding node_modules. We also had to make sure we ran it before babel transpilation.

// webpack.config.js

module: {
  rules: [
    {
      enforce: 'pre',
      test: /\.js$/,
      exclude: path.resolve(__dirname, 'node_modules'),
      loader: 'eslint-loader'
    },
    {
      test: /\.js$/,
      exclude: path.resolve(__dirname, 'node_modules'),
      include: [
        path.resolve(__dirname, 'src/js')
      ],
      loader: 'babel-loader'
    }
  ]
}

For rollup, we installed rollup-plugin-eslint and added it to our
array of plugins.

// rollup.config.js

// Add eslint to plugins
eslint(),
babel({
  exclude: 'node_modules/**'
})

This also needed to be added before babel still, to ensure it is run on the untranspiled code.

stylelint-webpack-plugin -> rollup-plugin-stylelint

Stylelint allows us to enforce linting rules for CSS and SCSS files.
We enforced this with stylelint-webpack-plugin previously,
but switched to rollup-plugin-stylelint for use with rollup.

First, we removed stylelint-webpack-plugin from our package.json and then added rollup-plugin-stylelint by running:

yarn add rollup-plugin-stylelint --dev

The options for both webpack and rollup are options passed directly to stylelint, so we mostly just needed to copy and paste these.

// webpack.config.js
new StyleLintWebpackPlugin({
  fix: false,
  syntax: 'scss',
  quiet: false
})

// rollup.config.js
stylelint({
  fix: false,
  include: ['src/**.scss'],
  syntax: 'scss',
  quiet: false
})

The one difference was we had to specify to only include scss files, since the input for rollup is always the JS, and we did
not want to include imported CSS, just SCSS.

Local Development

browser-sync-webpack-plugin -> rollup-plugin-browsersync

We use browsersync for local development of the demo/docs site, so we can see everything updating in real time across browsers.
This one was a fairly simple conversion.

First, we removed browser-sync-webpack-plugin from our package.json and then added rollup-plugin-browsersync by running:

yarn add rollup-plugin-browsersync --dev

The config for each plugin is basically identical, so we just copied from one to the other.

// webpack.config.js

new BrowserSyncPlugin(
      {
        host: 'localhost',
        watch: true,
        port: 3000,
        notify: false,
        open: true,
        server: {
          baseDir: 'docs/welcome',
          routes: {
            '/shepherd/dist/js/shepherd.js': 'dist/js/shepherd.js',
            '/shepherd/docs/welcome/js/prism.js': 'docs/welcome/js/prism.js',
            '/shepherd/docs/welcome/js/welcome.js': 'docs/welcome/js/welcome.js',
            '/shepherd/docs/welcome/css/prism.css': 'docs/welcome/css/prism.css',
            '/shepherd/docs/welcome/css/welcome.css': 'docs/welcome/css/welcome.css',
            '/shepherd/docs/welcome/sheep.svg': 'docs/welcome/sheep.svg'
          }
        }
      }, {
        reload: true
      }
    )

// rollup.config.js

// Only add the browsersync plugin if we are in development
if (process.env.DEVELOPMENT) {
  plugins.push(browsersync({
    host: 'localhost',
    watch: true,
    port: 3000,
    notify: false,
    open: true,
    server: {
      baseDir: 'docs/welcome',
      routes: {
        '/shepherd/dist/js/shepherd.js': 'dist/js/shepherd.js',
        '/shepherd/docs/welcome/js/prism.js': 'docs/welcome/js/prism.js',
        '/shepherd/docs/welcome/js/welcome.js': 'docs/welcome/js/welcome.js',
        '/shepherd/docs/welcome/css/prism.css': 'docs/welcome/css/prism.css',
        '/shepherd/docs/welcome/css/welcome.css': 'docs/welcome/css/welcome.css',
        '/shepherd/docs/welcome/sheep.svg': 'docs/welcome/sheep.svg'
      }
    }
  }));
}

Styles

sass-loader -> rollup-plugin-sass

In webpack we used a combination of sass-loader,
css-loader, postcss-loader,
file-loader, and extract-loader
to consume our scss files and output our various theme files.

// webpack.config.js
const glob = require('glob');
const sassArray = glob.sync('./src/scss/shepherd-*.scss');
const sassEntries = sassArray.reduce((acc, item) => {
  const name = item.replace('.scss', '').replace('./src/', '');
  acc[name] = item;
  return acc;
}, {});

...

module.exports = [{
  entry: sassEntries,
  output: {
    // This is necessary for webpack to compile
    // But we never use removable-style-bundle.js
    filename: 'removable-[id]-bundle.js'
  },
  module: {
    rules: [
      {
        test: /\.s[c|a]ss$/,
         include: [
           path.resolve(__dirname, 'src/scss')
         ],
         exclude: [
           path.resolve(__dirname, 'docs/welcome/scss')
         ],
         use: [
           {
             loader: 'file-loader',
             options: {
               name: 'css/[name].css'
             }
           },
           { loader: 'extract-loader' },
           { loader: 'css-loader' },
           {
             loader: 'postcss-loader',
             options: {
               plugins: () => [autoprefixer({ grid: false })]
             }
           },
           {
             loader: 'sass-loader',
             options: {
               sourceMap: false
             }
           }
         ]
      }
    ]
  }
}];

We were able to replace all of these loaders with just rollup-plugin-sass,
and postcss, when we switched to rollup. However, rollup has a hard time with
outputting multiple css files. It wants to consume all the styles and either bundle them as one file or just inject them into head
automatically for you. This made generating multiple theme files not very straightforward, but wasn't too bad, once we figured it out.

// rollup.config.js

const sassOptions = {
  output(styles, styleNodes) {
    fs.mkdirSync('dist/css', { recursive: true }, (err) => {
      if (err) {
        throw err;
      }
    });

    // Loop through the style nodes and manually write css files
    styleNodes.forEach(({ id, content }) => {
      const scssName = id.substring(id.lastIndexOf('/') + 1, id.length);
      const name = scssName.split('.')[0];
      fs.writeFileSync(`dist/css/${name}.css`, content);
    });
  },
  processor: css => postcss([
    atImport(),
    autoprefixer({
      grid: false
    })
  ])
    .process(css)
    .then(result => result.css)
};

...

plugins.push(sass(sassOptions));

Including tippy.js styles

In our webpack build, we aliased tippy.js, so that when it was imported, it would import the styles as well.

// webpack.config.js

resolve: {
  alias: {
    'tippy.js': 'tippy.js/dist/tippy.all.min.js'
  }
}

We initially tried to use an alias in rollup as well, but could not get it to work. We decided instead to use
rollup-plugin-css-only to handle CSS imports in the JS, and
we then injected those styles directly into the head.

// css.js

import { isBrowserSupported } from './browser';

/**
 * Injects a string of CSS styles to a style node in <head>
 * @param {String} css
 */
export function injectCSS(css) {
  if (isBrowserSupported) {
    const style = document.createElement('style');
    style.type = 'text/css';
    style.textContent = css;
    document.head.insertBefore(style, document.head.firstChild);
  }
}

// tour.js

import { injectCSS } from './css';
import tippy from 'tippy.js';
import tippyStyles from 'tippy.js/dist/tippy.css';

export class Tour extends Evented {
  constructor(){
    ...

    injectCSS(tippyStyles);
  }
}

Transpilation/Minification

babel-loader -> rollup-plugin-babel

Most modern web apps tend to use Babel, so they can use next generation JavaScript today. There isn't
a ton to configure with Babel, and it was mostly just switching packages, but we also did adjust our babel.config.js.

Before

// babel.config.js

module.exports = function(api) {
  api.cache(true);

  return {
    presets: [
      ['@babel/preset-env']
    ],
    plugins: [
      'add-module-exports',
      'lodash',
      'transform-es2015-modules-commonjs'
    ],
    env: {
      test: {
        plugins: ['istanbul']
      }
    }
  };
};

After

// babel.config.js

module.exports = function(api) {
  api.cache(true);

  return {
    presets: [
      [
        '@babel/preset-env',
        {
          modules: false
        }
      ]
    ],
    plugins: [
      '@babel/plugin-transform-object-assign'
    ],
    env: {
      test: {
        presets: [
          [
            '@babel/preset-env',
            {
              modules: false
            }
          ]
        ],
        plugins: [
          'transform-es2015-modules-commonjs'
        ]
      }
    }
  };
};

The main differences are we no longer needed istanbul because Jest has code coverage built in, and we switched around
our module exports and transforms, so we could ship both UMD and ESM.

After the Babel config changes, we removed babel-loader from our package.json and installed rollup-plugin-babel.

yarn add rollup-plugin-babel --dev

The usage in webpack and rollup is very similar, with the only option being to ignore node_modules.

// webpack.config.js

{
  test: /\.js$/,
  exclude: path.resolve(__dirname, 'node_modules'),
  include: [
    path.resolve(__dirname, 'src/js')
  ],
  loader: 'babel-loader'
}

// rollup.config.js

babel({
  exclude: 'node_modules/**'
})

uglifyjs-webpack-plugin -> rollup-plugin-uglify

Uglify is the most common package used for minification of JavaScript, and we used it with both webpack
and rollup, we just needed to switch which package we used.

First we removed uglifyjs-webpack-plugin from our package.json and then we installed
rollup-plugin-uglify.

yarn add rollup-plugin-uglify --dev

This was one place where the webpack build was a lot simpler. We added the uglify plugin and only included the min
file, so we could use one build.

// webpack.config.js

optimization: {
  minimizer: [
    new UglifyJsPlugin({
      include: /\.min\.js$/,
      sourceMap: true
    })
  ]
}

Then we added it to our rollup plugins, but to generate both a minified, and unminified version,
we were required to use two rollup builds, which was not required in webpack. We checked for the presence
of an environment variable DEVELOPMENT, and generated the minified version when true.

// rollup.config.js

if (!process.env.DEVELOPMENT) {
  rollupBuilds.push(
    // Generate minifed bundle
    {
      input: './src/js/shepherd.js',
      output: {
        file: 'dist/js/shepherd.min.js',
        format: 'umd',
        name: 'Shepherd',
        sourcemap: true
      },
      plugins: [
        resolve(),
        commonjs(),
        babel({
          exclude: 'node_modules/**'
        }),
        license({
          banner
        }),
        sass(sassOptions),
        css({ output: false }),
        uglify(),
        filesize()
      ]
    });
}

Config Files

For those of you who want to see the entire config for both webpack and rollup, to compare one to the other, here they are! It may also be helpful to
check out the PR where we converted from webpack to rollup, so you can see all the things involved.

Webpack

// webpack.config.js

/* global require, module, __dirname */
const webpack = require('webpack');
const path = require('path');
const autoprefixer = require('autoprefixer');
const BrowserSyncPlugin = require('browser-sync-webpack-plugin');
const LodashModuleReplacementPlugin = require('lodash-webpack-plugin');
const StyleLintWebpackPlugin = require('stylelint-webpack-plugin');
const UglifyJsPlugin = require('uglifyjs-webpack-plugin');
const PACKAGE = require('./package.json');
const banner = ['/*!', PACKAGE.name, PACKAGE.version, '*/\n'].join(' ');
const glob = require('glob');
const sassArray = glob.sync('./src/scss/shepherd-*.scss');
const sassEntries = sassArray.reduce((acc, item) => {
  const name = item.replace('.scss', '').replace('./src/', '');
  acc[name] = item;
  return acc;
}, {});

// Theme SCSS files
sassEntries['css/welcome'] = './docs/welcome/scss/welcome.scss';

module.exports = [{
  entry: sassEntries,
  output: {
    // This is necessary for webpack to compile
    // But we never use removable-style-bundle.js
    filename: 'removable-[id]-bundle.js'
  },
  module: {
    rules: [
      {
        test: /\.s[c|a]ss$/,
        include: [
          path.resolve(__dirname, 'src/scss')
        ],
        exclude: [
          path.resolve(__dirname, 'docs/welcome/scss')
        ],
        use: [
          {
            loader: 'file-loader',
            options: {
              name: 'css/[name].css'
            }
          },
          { loader: 'extract-loader' },
          { loader: 'css-loader' },
          {
            loader: 'postcss-loader',
            options: {
              plugins: () => [autoprefixer({ grid: false })]
            }
          },
          {
            loader: 'sass-loader',
            options: {
              sourceMap: false
            }
          }
        ]
      },
      {
        test: /welcome\.s[c|a]ss$/,
        include: [
          path.resolve(__dirname, 'docs/welcome/scss')
        ],
        use: [
          {
            loader: 'file-loader',
            options: {
              outputPath: '../docs/welcome/',
              name: 'css/[name].css'
            }
          },
          { loader: 'extract-loader' },
          {
            loader: 'css-loader',
            options: {
              sourceMap: true
            }
          },
          {
            loader: 'postcss-loader',
            options: {
              sourceMap: true,
              plugins: () => [
                autoprefixer({
                  grid: false,
                  browsers: [
                    'last 2 versions'
                  ]
                })]
            }
          },
          {
            loader: 'sass-loader',
            options: {
              outputStyle: 'expanded',
              sourceMap: true
            }
          }
        ]
      }
    ]
  },
  plugins: [
    new StyleLintWebpackPlugin({
      fix: false,
      syntax: 'scss',
      quiet: false
    }),
    new BrowserSyncPlugin(
      {
        host: 'localhost',
        watch: true,
        port: 3000,
        notify: false,
        open: true,
        server: {
          baseDir: 'docs/welcome',
          routes: {
            '/shepherd/dist/js/shepherd.js': 'dist/js/shepherd.js',
            '/shepherd/docs/welcome/js/prism.js': 'docs/welcome/js/prism.js',
            '/shepherd/docs/welcome/js/welcome.js': 'docs/welcome/js/welcome.js',
            '/shepherd/docs/welcome/css/prism.css': 'docs/welcome/css/prism.css',
            '/shepherd/docs/welcome/css/welcome.css': 'docs/welcome/css/welcome.css',
            '/shepherd/docs/welcome/sheep.svg': 'docs/welcome/sheep.svg'
          }
        }
      }, {
        reload: true
      }
    ),
    new webpack.BannerPlugin(banner)
  ]
}];

// Library Shepherd files
module.exports.push({
  entry: {
    'js/shepherd': './src/js/shepherd.js',
    'js/shepherd.min': './src/js/shepherd.js'
  },
  devtool: 'source-map',
  target: 'web',
  performance: {
    maxEntrypointSize: 512000,
    maxAssetSize: 512000
  },
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].js',
    library: 'Shepherd',
    libraryTarget: 'umd',
    globalObject: 'this',
  },
  resolve: {
    alias: {
      'tippy.js': 'tippy.js/dist/tippy.all.min.js'
    }
  },
  module: {
    rules: [
      {
        enforce: 'pre',
        test: /\.js$/,
        exclude: path.resolve(__dirname, 'node_modules'),
        loader: 'eslint-loader'
      },
      {
        test: /\.js$/,
        exclude: path.resolve(__dirname, 'node_modules'),
        include: [
          path.resolve(__dirname, 'src/js')
        ],
        loader: 'babel-loader'
      }
    ]
  },
  optimization: {
    minimizer: [
      new UglifyJsPlugin({
        include: /\.min\.js$/,
        sourceMap: true
      })
    ]
  },
  plugins: [
    new webpack.BannerPlugin(banner),
    new LodashModuleReplacementPlugin
  ]
});

Rollup

// rollup.config.js

import autoprefixer from 'autoprefixer';
import babel from 'rollup-plugin-babel';
import browsersync from 'rollup-plugin-browsersync';
import commonjs from 'rollup-plugin-commonjs';
import css from 'rollup-plugin-css-only';
import cssnano from 'cssnano';
import { eslint } from 'rollup-plugin-eslint';
import fs from 'fs';
import license from 'rollup-plugin-license';
import postcss from 'postcss';
import filesize from 'rollup-plugin-filesize';
import resolve from 'rollup-plugin-node-resolve';
import sass from 'rollup-plugin-sass';
import stylelint from 'rollup-plugin-stylelint';
import { uglify } from 'rollup-plugin-uglify';

const pkg = require('./package.json');
const banner = ['/*!', pkg.name, pkg.version, '*/\n'].join(' ');

const sassOptions = {
  output(styles, styleNodes) {
    fs.mkdirSync('dist/css', { recursive: true }, (err) => {
      if (err) {
        throw err;
      }
    });

    styleNodes.forEach(({ id, content }) => {
      const scssName = id.substring(id.lastIndexOf('/') + 1, id.length);
      const name = scssName.split('.')[0];
      fs.writeFileSync(`dist/css/${name}.css`, content);
    });
  },
  processor: css => postcss([
    autoprefixer({
      grid: false
    }),
    cssnano()
  ])
    .process(css)
    .then(result => result.css)
};

const plugins = [
  resolve(),
  commonjs(),
  stylelint({
    fix: false,
    include: ['src/**.scss'],
    syntax: 'scss',
    quiet: false
  }),
  eslint(),
  babel({
    exclude: 'node_modules/**'
  }),
  css({ output: false })
];

if (!process.env.DEVELOPMENT) {
  plugins.push(sass({
    output: false
  }));
}

// If we are running with --environment DEVELOPMENT, serve via browsersync for local development
if (process.env.DEVELOPMENT) {
  plugins.push(sass(sassOptions));

  plugins.push(browsersync({
    host: 'localhost',
    watch: true,
    port: 3000,
    notify: false,
    open: true,
    server: {
      baseDir: 'docs/welcome',
      routes: {
        '/shepherd/dist/css/shepherd-theme-default.css': 'dist/css/shepherd-theme-default.css',
        '/shepherd/dist/js/shepherd.js': 'dist/js/shepherd.js',
        '/shepherd/docs/welcome/js/prism.js': 'docs/welcome/js/prism.js',
        '/shepherd/docs/welcome/js/welcome.js': 'docs/welcome/js/welcome.js',
        '/shepherd/docs/welcome/css/prism.css': 'docs/welcome/css/prism.css',
        '/shepherd/docs/welcome/css/welcome.css': 'docs/welcome/css/welcome.css',
        '/shepherd/docs/welcome/sheep.svg': 'docs/welcome/sheep.svg'
      }
    }
  }));
}

plugins.push(license({ banner }));
plugins.push(filesize());

const rollupBuilds = [
  // Generate unminifed bundle
  {
    input: './src/js/shepherd.js',

    output: [
      {
        file: pkg.main,
        format: 'umd',
        name: 'Shepherd',
        sourcemap: true
      },
      {
        file: pkg.module,
        format: 'esm',
        sourcemap: true
      }
    ],
    plugins
  }
];

if (!process.env.DEVELOPMENT) {
  rollupBuilds.push(
    // Generate minifed bundle
    {
      input: './src/js/shepherd.js',
      output: {
        file: 'dist/js/shepherd.min.js',
        format: 'umd',
        name: 'Shepherd',
        sourcemap: true
      },
      plugins: [
        resolve(),
        commonjs(),
        babel({
          exclude: 'node_modules/**'
        }),
        license({
          banner
        }),
        sass(sassOptions),
        css({ output: false }),
        uglify(),
        filesize()
      ]
    });
}

export default rollupBuilds;

Summary

The webpack build of shepherd.min.js was ~80 kb and the rollup build was ~25% smaller, at ~60 kb. Although getting rollup set up and working
is a lot more involved, and there are less examples than webpack, it is clearly worth the effort, for the bundle size savings alone.

Unit Testing Private, Non-exported Functions with Rewire

Robert Wagner — Mon, 18 Nov 2019 16:55:28 +0000

Originally published at shipshape.io

When a JavaScript function is exported, it is straightforward to unit test.
We can import it directly into our test and test the functionality. For example,
we could use something like Jest to setup a simple import and unit test.

// foo.js

export function foo() {
  return 'bar';
}

// foo.spec.js

import { foo } from './foo.js'

describe('Foo', () => {
  describe('foo', () => {
    expect(foo()).toBe('bar');
  });
});

How would we test functions that we do not expose via export though?

There is a great tool, rewire, that allows getting references
to functions that are not explicitly exported. Assuming you are using Babel, we can use
babel-plugin-rewire to make the setup more simple.

  npm install babel-plugin-rewire --save-dev

Then we need to add it to our plugins for testing, in our babel.config.js.

...
plugins: [
  'babel-plugin-rewire',
  ...
]
...

We can then import the whole file, and get references to the non-exported functions, using
__get__.

// bar.js

function _bar() {
  return 'baz';
}

// bar.spec.js

import Bar from './bar.js'

describe('Bar', () => {
  describe('_bar', () => {
    const _bar = Bar.__get__('_bar');
    expect(_bar()).toBe('baz');
  });
});

Rewire makes this setup downright magical, and saves us from needing to needlessly export things
or use other hacks, just to get a reference to the function for testing. We can now ensure functions
remain private, without all the headaches at testing time!

DEV Community: Robert Wagner

Top 5 Web Developer Tools for 2023

When was the last time you updated your web development tools?

1. Arc

2. Warp

3. Zed

4. GitHub Desktop

5. Fig

Wrap-up

Top 5 JavaScript Podcasts for 2023

Which JavaScript podcasts are the hottest?

1. Syntax

2. Shop Talk Show

3. JS Party

4. Whiskey Web and Whatnot

5. Front End Happy Hour

Wrap-up

5 Tips to Improve Your Terminal Experience

Fish

Starship

MonoLisa

Hyper

asdf

Launching Electron Apps From the Browser

Electron app -> browser

Browser -> Electron app

macOS

electron-forge

electron-builder

Windows

Final Result

Tailwind UI Dropdowns with Ember

Releasing JavaScript Libraries with release-it

Signing Electron Apps with GitHub Actions

MacOS

Getting your certificate from Apple

Adding your certificate to GitHub

Calling the script in GitHub actions

Notarizing your MacOS app

Entitlements and other settings

Windows

Building the application

Converting a Webpack Build to Rollup

Table of Contents

Linting

eslint-loader -> rollup-plugin-eslint

stylelint-webpack-plugin -> rollup-plugin-stylelint

Local Development

browser-sync-webpack-plugin -> rollup-plugin-browsersync

Styles

sass-loader -> rollup-plugin-sass

Including tippy.js styles

Transpilation/Minification

babel-loader -> rollup-plugin-babel

Before

After

uglifyjs-webpack-plugin -> rollup-plugin-uglify

Config Files

Webpack

Rollup

Summary

Unit Testing Private, Non-exported Functions with Rewire