DEV Community: Ben Gubler

Super excited to share! Thoughts?

Ben Gubler — Wed, 17 Sep 2025 20:15:31 +0000

Ben Gubler

Sep 17 '25

Introducing ts-base: A Modern TypeScript Library Template

#webdev #opensource #typescript #programming

Comments

6 min read

Introducing ts-base: A Modern TypeScript Library Template

Ben Gubler — Wed, 17 Sep 2025 20:09:07 +0000

Eight years ago, I released my first open-source TypeScript library — Squirrelly — which contained two files, package.json and index.js. Five years ago, I released Eta with many more features including testing, linting, bundling, and CI/CD.

I thought was a pretty solid development setup, but times change and the JavaScript ecosystem moves fast. New tools have emerged, best practices have evolved, and the complexity of properly publishing an npm package has somehow gotten both easier and more overwhelming at the same time.

Just look at the package.json "exports" field evolution if you want a headache. Or try figuring out the right combination of TypeScript configs, bundlers, and CI workflows to publish a library that works seamlessly across Node, Deno, Bun, and browsers. It's surprisingly tricky to get right.

That's why I built ts-base — a modern TypeScript library starter template that handles all of this complexity for you. It's opinionated, battle-tested, and designed to work out-of-the-box with every major JavaScript runtime.

What is ts-base?

ts-base is a TypeScript library template that embraces modern tooling and automated workflows. Instead of starting from scratch or copying outdated boilerplate, you get a complete development environment that includes linting, testing, building, releasing, and publishing — all pre-configured and ready to go.

The template is built around three core principles:

Multi-runtime first: Works seamlessly across Node, Deno, Bun, and browsers
Automation over configuration: Minimal setup, maximum automation
Modern tooling: ESM-only, latest TypeScript, and carefully chosen dependencies

Multi-Runtime Architecture

The heart of ts-base is its runtime-agnostic design. Instead of trying to make one file work everywhere (and dealing with compatibility headaches), the template uses a clean separation:

// src/internal.ts - Core logic, no runtime-specific APIs
export function add(a: number, b: number): number {
  return a + b;
}

export function greet(name: string, options = {}): string {
  const base = `Hello, ${name}`;
  return options.shout ? `${base.toUpperCase()}!` : `${base}.`;
}

// src/index.ts - Node/Bun adapter
export { add, greet } from "./internal";
import { randomBytes } from "node:crypto";

export function getSecureRandomId(): string {
  const timePart = Date.now().toString(36);
  const bytes = randomBytes(12).toString("base64url");
  return `${timePart}-${bytes}`;
}

// src/browser.ts - Browser adapter
export { add, greet } from "./internal";

export function getSecureRandomId(): string {
  const timePart = Date.now().toString(36);
  const array = new Uint8Array(12);
  crypto.getRandomValues(array);
  const rand = btoa(String.fromCharCode(...array))
    .replaceAll("+", "-")
    .replaceAll("/", "_")
    .replaceAll("=", "");
  return `${timePart}-${rand}`;
}

This gives you clean imports for every runtime:

// Node/Bun
import { add, getSecureRandomId } from "@your-package/ts-base";

// Browser (via bundler)
import { add, getSecureRandomId } from "@your-package/ts-base/browser";

// Deno (direct TypeScript imports)
import {
  add,
  greet,
} from "https://jsr.io/@bgub/ts-base/<version>/src/index.ts";

The build system uses tsdown to create two optimized bundles: one for Node environments and a separate minified bundle for browsers, both with sourcemaps.

Developer Experience

ts-base consolidates your tooling around a few excellent choices:

Biome replaces both ESLint and Prettier with a single, fast tool. No more configuration conflicts or plugin incompatibilities — just consistent formatting and linting that works out of the box.

Vitest provides lightning-fast testing with built-in coverage reporting and customizable thresholds. Tests run in parallel, support TypeScript natively, and include helpful features like mocking and snapshots.

Size Limit monitors your bundle size automatically. It runs in CI and comments on pull requests when your changes would increase the bundle size, helping you catch bloat before it ships.

The TypeScript configuration is optimized for modern bundlers with settings like moduleResolution: "bundler" and allowImportingTsExtensions: true that work great with tools like Vite, Rollup, and esbuild.

Automated CI/CD Pipeline

One of ts-base's biggest strengths is its complete CI/CD setup. Every aspect of code quality and publishing is automated:

Quality Gates: Every pull request triggers linting, type checking, testing, and coverage reporting. The CI uploads coverage to Codecov and comments on PRs with size impact reports.

Release Management: Instead of complex semantic-release configurations, ts-base uses Google's Release Please. When commits land on main, Release Please automatically opens a "Release PR" that updates version numbers, generates changelogs, and creates release tags.

Automated Publishing: When you merge the Release PR, GitHub Actions automatically builds and publishes your package to both npm and JSR with full OIDC provenance and security attestation.

Conventional Commits: PR titles are automatically linted to follow conventional commit format, ensuring consistent changelog generation.

Why This Approach Works Better

Most TypeScript library templates I've seen are either too minimal (leaving you to figure out CI, publishing, and multi-runtime support) or overcomplicated with dozens of dependencies. I've seen templates with packages like @commitlint/cli, @commitlint/config-conventional, @semantic-release/changelog, @semantic-release/git, @semantic-release/github, @semantic-release/npm, and more just for CI publishing!

ts-base takes a different approach with just 8 total dev dependencies. By choosing Release Please over semantic-release, Biome over ESLint+Prettier, and Vitest over Jest, you get a simpler dependency graph that's easier to maintain and less likely to break.

The automation philosophy means less configuration and fewer places for things to go wrong. Release Please handles version bumping, changelog generation, and release creation in one tool. The GitHub Actions workflows handle everything else.

The Magic of Release Please

Release Please deserves special attention because it transforms how you think about releases. Instead of manually bumping versions or configuring complex semantic-release pipelines, Release Please works like this:

You merge commits to main using conventional commit messages
Release Please automatically opens/updates a "Release PR" with version bumps and changelog entries
When you're ready to release, simply merge the Release PR
GitHub Actions automatically publishes to npm and JSR

The system supports pre-releases too. If you release an alpha or beta version, it automatically publishes under the "next" tag on npm. You can override version bumps using Release-As: 2.0.0 in commit messages, and you can maintain multiple release branches (like 2.x and 3.x) that each get their own Release PRs.

Getting Started

Setting up ts-base is straightforward:

Clone and customize: Clone the repository, remove the .git folder, and update package.json, jsr.json, and .release-please-manifest.json with your package details.
Claim your package: Set the version to 0.0.0 in all config files, then run npm publish locally to claim your package name on npm.
Configure publishing: In npm, set your package to require 2FA for authorization only (not publishing), then add your GitHub workflow as a trusted publisher. On JSR, create your package and add the repository as a trusted source.

Set up GitHub: Push to GitHub, add CODECOV_TOKEN as a repository secret, and configure branch protection rules.
Start developing: Add your code to src/, write tests, and push commits. Release Please will handle the rest.

I recommend configuring GitHub to only allow squash merging and using "pull request title and commit details" as the default commit message. This keeps your commit history clean and ensures conventional commit compliance.

Best Practices & Tips

Repository Settings: Enable branch protection on main with required status checks. Disable merge commits to keep history linear.

Entry Points: Use the main export (@your-package) for Node/Bun, the browser export (@your-package/browser) for bundled browser code, and direct TypeScript imports for Deno.

Customization: If you don't need separate Node/browser builds, delete the unused configuration. The template is designed to be trimmed down to your specific needs.

Testing Strategy: The template includes examples of testing both shared and platform-specific code, including mocking browser APIs in the Node test environment.

Wrapping Up

Publishing a TypeScript library shouldn't require a PhD in tooling configuration. ts-base gives you a modern, opinionated foundation that handles the complexity so you can focus on building great software.

The template represents eight years of lessons learned from maintaining open source projects. Ready to try it out? Check out the ts-base repository and start building your next library.

One config file to rule them all

Ben Gubler — Mon, 03 Jul 2023 19:41:30 +0000

Modern web development involves working with multiple JS build tools and frameworks, each requiring their own configuration files. Managing these configuration files, such as .eslintrc, next.config.js, and tailwind.config.js, can become cumbersome and time-consuming. In this blog post, I'll explore the idea of combining these configuration files into a single file called global.config.js, centralizing project configuration and reducing distractions.

Config files everywhere

As I'm writing this blog post, my project root contains an .eslintrc.json, next.config.js, postcss.config.js, tailwind.config.js, and tsconfig.json. Although my configuration is pretty out-of-the-box and each file is less than 30 lines, those files take up valuable space in my VSCode sidebar and distract from what's important: my source code.

My case is far from exceptional. Some other projects use far more configuration files. Imagine how cluttered a project can get when you add a .babelrc, prettier.config.js, jest.config.js, cypress.json, etc.

The solution: `global.config.js`

I'd like to propose a simple solution: consolidating configuration files in a file called global.config.js. The configuration for each tool would be stored in the exported object, under a key with the name of the npm package.

Projects should still allow usage of individual configuration files for cases when configuration is large and complex (e.g. tsconfig.json), but should first scan to see if a global.config.js exists and configuration for their tool is present.

Here's what a simple global.config.js might look like:

module.exports = {
  eslint: {
    extends: ["next/core-web-vitals"]
  },
  postcss: {
    plugins: {
      tailwindcss: {},
      autoprefixer: {}
    }
  },
  tailwindcss: {
    content: ["./src/pages/**/*.{js,ts,jsx,tsx,mdx}"],
    theme: {
      extend: {
        backgroundImage: {
          "gradient-radial": "radial-gradient(var(--tw-gradient-stops))"
        }
      }
    },
    plugins: [require("@tailwindcss/typography")]
  }
}

But what about types?

Type completion can be easily enabled for global.config.js by adding type definitions in comments, like Tailwind and NextJS already do in their config files.

module.exports = {
  // ...

  /** @type {import('tailwindcss').Config} */
  tailwindcss: {
    content: ["./src/pages/**/*.{js,ts,jsx,tsx,mdx}"],
    theme: {
      extend: {
        backgroundImage: {
          "gradient-radial": "radial-gradient(var(--tw-gradient-stops))"
        }
      }
    },
    plugins: [require("@tailwindcss/typography")]
  }
}

Next steps

If you like this idea, submit a PR to your favorite build tool! If you don't, let me know why on Twitter. Or don't and just keep going about your life.

If you liked the article, don't forget to share it and follow me at @nebrelbug on Twitter.

Introducing Eta v3

Ben Gubler — Fri, 23 Jun 2023 03:52:39 +0000

Background

Today, Eta is my most popular and widely used open-source project. But when I first published it 3 years ago, it wasn't one of my primary focuses. In fact, I created Eta as a slimmed-down variation of Squirrelly, a more complex template engine with features like helpers and filters.

As time passed, I realized that for most projects, an embedded template engine was actually a better fit than something more complex. Projects which needed complex or client-side HTML processing typically used a framework like React or Vue. Eta's performance and low bundle size, meanwhile, made it a great fit for projects which needed fast processing, low memory usage, or to handle non-XML languages.

At the same time, Eta had become increasingly popular thanks to its speed, Deno support, and syntactic advantages over EJS. Given those factors, I decided to make Eta my main focus. I spent time writing tutorials, fixing issues, and polishing documentation.

After several years and some time spent away from programming as a missionary, I finally had time to work on Eta again. I decided to make some big changes to the project, including the build system, API, and documentation.

Build System Updates

Despite Eta's advantages and features, it had some big problems. One such problem was the build system. Complex and unwieldy, it was difficult to maintain and update. I dealt with complex configuration files and the necessity of transpiling a version specifically for Deno.

Changes in version 3:

Using microbundle to bundle the library helped me avoid the need for complex configuration files.
Using GitHub Actions to run tests and collect coverage allowed me to consolidate the services I used.
By setting allowImportingTsExtensions: true in tsconfig.json, I was able to avoid using Denoify for a separate Deno build.

API Changes

Another problem was the API. Simple methods like eta.render() had many function overloads, making types difficult to infer and usage unintuitive. A custom configuration object could be passed in when calling user-exposed functions like render, parse, and compile. In practice, that meant the user-provided configuration had to be merged with the default configuration every time any of those functions was called.

Changes in version 3:

There's only one export, a named class called Eta. This class has a single constructor, which processes a configuration object and generates template caches at instantiation time.
The render() and renderAsync() functions now have a single function signature.
- In Eta v2, render() and renderAsync() could be used to render either named templates or template strings. Eta v3 introduces two new functions to render template strings: renderString() and renderStringAsync().
The readFile() and resolvePath() functions, which Eta uses internally, can be overridden as class methods by the user.
Internal variables and methods inside each compiled template are stored in the eta object, rather than across several variables including res.
Rather than allowing users to specify one root directory and multiple views directories, users may just specify a single views directory. This directory is used as the root directory for all template resolution. All template files must be inside this directory or a subdirectory of it, improving template security and reducing expensive file-lookup operations.

Developer Experience Changes

One of the biggest changes in Eta v3 was the addition of detailed runtime errors (inspired by EJS). Consider a template like the following, which will throw because of an undefined variable:

Template header
<%= undefinedVariable %>
Lorem Ipsum

Eta v2 would throw an error with some generic info, but it wasn't incredibly helpful. In contrast, Eta v3 throws a detailed error with the template name, line number, and error message:

EtaError [ReferenceError]: .../my-dir/templates/runtime-error.eta:2
    1| Template header
 >> 2| <%= undefinedVariable %>
    3| Lorem Ipsum

undefinedVariable is not defined

Documentation Changes

The documentation for Eta v2 was extensive but very difficult to navigate. Information about the project was split over 40+ (!) documentation pages, found in multiple folders spread across 3 different website sections.

The documentation for Eta v3 takes up 9 pages, all found in the same part of the website (eta.js.org). Topics like template syntax and API overview are covered in a single page, rather than being split across multiple pages.

The Future of Eta

I'm proud of the changes included in Eta v3, and of the project as a whole. Much thanks to those who contributed to the project through PRs, issues, and suggestions. Additional thanks to projects like ejs, from which Eta continues to draw inspiration.

I see Eta as mostly feature-complete at this point, though I'll continue to fix bugs and add some small features. I'd encourage current users of the library to upgrade to v3, and I hope new users will find Eta to be a great fit for their projects.

Links

If you liked the article, don't forget to share it and follow me at @nebrelbug on Twitter.

Looking for a new lead maintainer for the Eta template engine

Ben Gubler — Fri, 09 Oct 2020 13:24:43 +0000

Hey everyone, this is @nebrelbug -- the lead maintainer of the Eta template engine and its companion project, Squirrelly.

On October 28, 2020, I will leave on a 2-year service opportunity. During that time, I will be unable to work on any of my open-source projects.

Since my date of departure is drawing closer, I've decided it is time to begin looking for a new lead maintainer for Eta.

Maintainer Requirements

Proficiency in TypeScript
Open-source experience. Preferably the maintainer/developer of an open-source JS/TS project with 50+ stars
Willing to test changes & not break anything important 😉
Willing to follow the Project Goals (see below)

Maintainer Jobs

Fix bugs
Answer questions

A maintainer could also update documentation, write tutorials, write plugins, write integrations (ex. for Fastify, Eleventy, Koa) etc. In case this sounds overwhelming, remember that Eta is only 2.5KB minzipped 😂

Ideally a maintainer would be willing to maintain Squirrelly as well (they share much of the same codebase) but that's definitely not a requirement.

Project Goals

Follow SemVer versioning guidelines
- This means Eta's public API should remain backwards-compatible (at least within v1.x.x)
Remain lightweight
- Browser build should never exceed 3KB minzipped
Remain stable
Keep parsing engine
- Eta's parser has been optimized quite a bit for performance and reliability, and any significant changes run too high a risk of impacting either

Fallback Plan

There's always the possibility I will be unable to find a new lead maintainer before my departure. This is one of the reasons I've accelerated development so much. It's also the reason Eta and Squirrelly are so extensively tested.

I feel confident that Eta is stable enough it could continue to function, if needs be, without maintenance for several years. It has a stable API, is well tested, and has decent documentation. Many features can be added as 3rd-party plugins rather than core parts of the library. Moreover, Eta's small size reduces the likelihood that important bugs exist inside the code.

That scenario, though, would be far from ideal, so I've made several backup plans:

Give repository + npm access to a friend I trust to act in my behalf. This friend would not modify Eta's code, but could give access if, while I was gone, someone asked to become a maintainer
Add the project to https://www.codeshelter.co/

TL;DR

I'm going to be away for 2 years and unable to maintain Eta.

In case I am unable to find a maintainer before I leave, I will give repository access to a trusted friend and add the repository to https://www.codeshelter.co/ (allowing anyone to apply for maintainership).

If you want to become one of Eta's maintainers and have experience with open-source and TypeScript, message me on Gitter, email me at nebrelbug [at] gmail [dot] com, or contact me some other way!

Adding Deno support to the Eta template engine

Ben Gubler — Mon, 14 Sep 2020 14:43:19 +0000

How I added Deno support to my module, Eta, using Denoify

Background

A few months ago I wrote about my creation of Eta, an embedded JavaScript template engine.

Article No Longer Available

Since then, Eta has met with a fair bit of success (it's now used by Facebook's popular Docusaurus library to generate SSR pages) and has seen quite a few updates.

I was particularly excited to add Deno support. Since Deno is relatively new, not many template engines are compatible with it, and none of them are as full-featured as Eta. Additionally, Eta is written in TypeScript, which is ideal for Deno modules because Deno has built-in support for TypeScript.

Libraries like EJS and lodash.template are still far more popular than Eta for Node.js users, despite being less lightweight, less reliable, and slower. I hoped that adding Deno support to Eta would increase its popularity where older libraries weren't an option.

Challenges

I knew actually porting the module to use Deno's syntax would be quite easy. All I needed to do was add the .ts ending to imports and use Deno's standard library instead of Node built-ins like fs.

I could see a few challenges, though. First of all, Eta needed to continue working with Node.js. Using Deno, you import modules using URLs:

import  *  as  fs  from  "https://deno.land/std@0.66.0/fs/mod.ts"

This definitely does not work in Node.js and will cause errors.

Second, Deno resolves file paths differently than Node.js with TypeScript. Using the file extension .ts in imports – like import someMod from './some-mod.ts' – causes Node to throw an error, but not specifying the extension causes Deno to throw an error.

Finally, I planned to host Eta on https://deno.land/x, Deno's 3rd-party module registry. I wanted users to be able to import the module using a short URL, like this:

import * as eta from "https://deno.land/x/eta/mod.ts";

Rather than having to specify a long nested directory path, like this:

import * as eta from "https://deno.land/x/eta/dist/deno/mod.ts";

The Solution

After a bit of internet research, I found a library called Denoify. Denoify is a build tool that takes TypeScript source files and outputs files built for Deno.

Denoify automatically converts import paths to work with Deno, converting statements like this:

import { myFunc } from './my-func'

To this:

import { myFunc } from './my-func.ts'

The main advantage of Denoify, though, is that it lets you provide a Deno-specific implementation of your files.

Say you have a file, file-handlers.ts, that requires the Node fs module. With Denoify, you can create a file-handlers.deno.ts file that uses Deno's standard library fs instead.

Denoify will automatically swap out the override file when you build (this will sound familiar to users of React Native, which has a feature this was based on). It turns out this is a super helpful feature.

In my case, I was able to extract all my file handling logic into one file called file-methods.ts, and created a Deno-specific implementation at file-methods.deno.ts. Other scripts could import ... from './file-methods' just like normal, but file-methods.ts itself was a different file inside the Deno build.

Testing

The last thing I had to do before release was add testing for the Deno build. Luckily, Deno has a built-in assertions module. Its syntax is fairly similar to other assertion libraries I'd used – as an example, here's a simple test I wrote.

import { assertEquals } from 'https://deno.land/std@0.67.0/testing/asserts.ts'
import { render } from '../../deno_dist/mod.ts'

Deno.test('simple render', () => {
  const template = `Hi <%=it.name%>`
  assertEquals(eta.render(template, { name: 'Ben' }), 'Hi Ben')
})

I ended up creating a small subdirectory named deno/ inside my main tests folder. There I put several tests that focused mainly on general functionality (just in case somehow the build went wrong and everything broke) and file handling (Eta has, as described above, unique file handling code for Deno).

Final Steps

It turns out that linters, test files, and documentation generators try to operate on every single file they see within their input directory, even if it isn't directly in their test path.

I spent a lot of time figuring out how to:

Make ESLint ignore *.deno.ts files
Make Prettier not try to format Deno files
Make Jest ignore the test/deno subdirectory
Make Coveralls ignore the test/deno subdirectory
Make TypeDoc ignore Deno files
Etc.

Finally, though, I got all of my Deno files correctly ignored. I added the denoify command to my build script, and ... voila! Eta supported Deno!

Publishing

One really nice feature of https://deno.land/x is that it supports adding a module that lives in the subdirectory of a Git repository. In my case, I configured denoify to create an output folder called deno_dist. This folder contains all of Eta's source files, as well as README.md and LICENSE.

I added Eta to https://deno.land/x, so users can view and import it from https://deno.land/x/eta. The registry automatically updates the module, thanks to webhooks, every time I create a new tagged release.

Conclusion

So there we have it, an account of how I gave my npm package Deno support! I hope this helps any who are working to bring Deno support to their packages and libraries. Don't hesitate to ask in the comments if you have any questions!

⚡ Obligatory shameless plug ⚡

If you're looking for a template engine for your next Deno project, try Eta! It's lightweight, has great performance, and is super configurable.

Check out Eta's documentation, or see examples of Eta being used with Opine and Alosaur!

I built a JS template engine 3x faster than EJS

Ben Gubler — Sat, 11 Apr 2020 15:33:46 +0000

After hundreds of hours of development, I finally released my open-source project last week. Eta is a pluggable, lightweight, and super-fast JavaScript template engine I created to serve as an alternative to doT and EJS.

Before I get into discussing my development journey, though, let me outline some differences between Eta and EJS.

Eta vs EJS
Eta's syntax is very similar to EJS' (most templates should work with either engine), Eta has a similar API, and Eta and EJS share the same file-handling logic. Here are the differences between Eta and EJS:

Eta is more lightweight. Eta weighs around 2KB gzipped, while EJS is 4.4KB gzipped
Eta compiles and renders templates much faster than EJS. Check out these benchmarks: https://ghcdn.rawgit.org/eta-dev/eta/master/browser-tests/benchmark.html
Eta allows left whitespace control (with -), something that doesn't work in EJS because EJS uses - on the left side to indicate that the value shouldn't be escaped. Instead, Eta uses ~ to output a raw value
Eta gives you more flexibility with delimeters -- you could set them to {{ and }}, for example, while with EJS this isn't possible
Eta adds plugin support
Comments in Eta use /* ... */ which allows commenting around template tags and is more consistent
Eta parses strings correctly. Example: <%= "%>" %> works in Eta, while it breaks in EJS
Eta exposes Typescript types and distributes a UMD build
Custom tag-type prefixes. Example: you could change <%= to <%*

Features Eta and EJS share

Async support
Partials support
File-handling support
- Eta borrows its file-handling code from EJS, which has over 1.5 million downloads / week. It's pretty reliable 😉
Express.js support
EJS syntax-highlighting tools work to some extent with Eta

Why did I build Eta?

My journey started around 2 years ago, when I first created a template engine called Squirrelly. After hundreds of hours of performance benchmarking and trying dozens of different parsing methods, I was finally able to break the speed of all other popular template engines.

Over the last year, I've been working on the next version of Squirrelly, which adds some important features like template inheritance and better string parsing. While benchmarking Squirrelly, I realized that it was significantly faster than other template engines like EJS -- even though it supported helpers, filters, template inheritance, etc.

I decided to take the framework behind Squirrelly (all of the behind-the-scenes code) which I had already optimized and tested extensively, and create a simple embedded template engine on top of it. The new template engine would be more configurable than most other template engines, extremely lightweight, very fast, and more reliable than most other template engines.

I named the new template engine "eta" for a few reasons.
1) Eta means "tiny" in Esperanto, and Eta is a tiny template engine
2) Eta is the name of a letter in the Greek alphabet, which I use as a cool logo
3) "Eta" is 3 letters long, which makes it easy to write template files (ex. footer.eta)

Within several weeks, I was able to create Eta. Because I didn't have to worry about Squirrelly's advanced features, Eta took significantly less time to create and test. Using Docusaurus v2, I was able to throw up a documentation site and write a playground.

A few lessons learned

In JavaScript (at least the v8 engine) regular expressions are super optimized and are significantly faster than even looping through every character in a string and doing something with it
TypeScript catches a lot of stupid errors
Running code coverage tests helps find unnecessary (dead) code
Performance can be improved significantly by lots of trial-and-error testing
with () {} in JavaScript slows down execution and can cause confusing bugs

Eta's Stack

Written in TypeScript
Compiled with Rollup (which, for libraries, creates much smaller builds than Webpack)
Minified with rollup-plugin-terser
Tests with Jest
Code-coverage with Coveralls
Travis CI for Continuous Integration
Prettier for formatting
ESLint with StandardJS compatibility for linting
TypeDoc for automatic API Doc Generation

I hope you enjoyed reading about my journey to create Eta! If you need an embedded JavaScript template engine for a future project, consider using Eta instead of a library like EJS or doT.

DEV Community: Ben Gubler

Super excited to share! Thoughts?

Introducing ts-base: A Modern TypeScript Library Template

Introducing ts-base: A Modern TypeScript Library Template

What is ts-base?

Multi-Runtime Architecture

Developer Experience

Automated CI/CD Pipeline

Why This Approach Works Better

The Magic of Release Please

Getting Started

Best Practices & Tips

Wrapping Up

One config file to rule them all

Config files everywhere

The solution: global.config.js

But what about types?

Next steps

Introducing Eta v3

Background

Build System Updates

API Changes

Developer Experience Changes

Documentation Changes

The Future of Eta

Links

Looking for a new lead maintainer for the Eta template engine

Maintainer Requirements

Project Goals

Fallback Plan

TL;DR

Adding Deno support to the Eta template engine

Background

Article No Longer Available

Challenges

The Solution

Testing

Final Steps

Publishing

Conclusion

I built a JS template engine 3x faster than EJS

Why did I build Eta?

A few lessons learned

Eta's Stack

The solution: `global.config.js`