DEV Community: Michal Bryxí

ember-template-lint recommended rules that I disable

Michal Bryxí — Tue, 05 Aug 2025 16:49:09 +0000

EmberJS comes with great set of default tooling. One of them is ember-template-lint which helps making sure that our *.hbs, *.gjs and *.gts files are following one format.

Sadly template-linter has no awareness of JS-scope at the moment and so sometimes it complains about things that are not really an issue.

I'm a big fan of frontile.dev for my forms and so I use their <Input /> element a lot. This confuses template linter which shouts at me various not so helpful things. So I found out that following set of "recommended" rules is actually good to disable:

// template-lintrc.js

'use strict';

module.exports = {
  extends: 'recommended',
  rules: {
    'require-input-label': false,
    'no-builtin-form-components': false,
    'no-unknown-arguments-for-builtin-components': false,
  },
};

Swiss trail closures in Locus

Michal Bryxí — Mon, 07 Apr 2025 19:05:11 +0000

Locus is the mapping app of choice for me for any use-case on Android and for most use-cases on desktop as well.

Although Locus does have Swisstopo layers, it does not have direct access to some of the extra WMS layers that are provided by the Swiss authorities.

This specifically hit me back when I planned my hike (using Locus) through a Sperrungen Wanderwege (closed trails), because I did not see those trails as (temporarily) closed on Locus.

The solution for this is to add a WMS layer to Locus using following URL:

https://wms.geo.admin.ch? SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&layers=ch.astra.wanderland-sperrungen_umleitungen

The argument layers=ch.astra.wanderland-sperrungen_umleitungen is there so that we're importing only the trail closures layer. Otherwise there will be hundreds of them. List of all available WMS layers for geo.admin.ch is a useful reference.

Embroider & Vite & net::ERR_ABORTED 504 (Outdated Optimize Dep)

Michal Bryxí — Sun, 30 Mar 2025 15:38:13 +0000

While working on EmberJS projects, I've been using pre-alpha version of @embroider/app-blueprint quite a lot lately and I hit a baffling error:

1) App builds and everything works
2) Sometimes, when the dev server is restarted (ctrl+c & pnpm start), the network tab of the app fails many requests with:

GET
http://localhost:4200/node_modules/.vite/deps/ember-source_@ember_application_index__js.js?v=4536db21
net::ERR_ABORTED 504 (Outdated Optimize Dep)

3) Nothing helps: Wiping node_modules; Setting the server to run with vite --force; Getting earlier versions of the app;
4) Sometimes everything builds fine and I can develop without any issue.

I discussed this very issue on EmberJS Discord and was pointed to pay attention at the console build errors, which actually did have some weird messages in it. I just never paid attention, because initially everything built fine:

pnpm start

> nuudel-to-ics@0.0.0 start /Users/michal/pudr.com/nuudel-to-ics
> vite --force

- Building

Environment: development

- Building

- building... 



Build successful (276ms)

9:45:36 AM [vite] (client) Forced re-optimization of dependencies

Slowest Nodes (totalTime >= 5%) | Total (avg)
-+-
Babel: ember-tracked-storage-polyfill (1) | 115ms
Funnel (109) | 33ms (0 ms)
BroccoliMergeTrees (202) | 31ms (0 ms)
Babel: ember-intl (2) | 21ms (10 ms)
@embroider/compat/addons (1) | 15ms



  VITE v6.2.3  ready in 2638 ms

  ➜  Local:   http://localhost:4200/
  ➜  Network: use --host to expose
  ➜  press h + enter to show help
✘ [ERROR] Cannot read file: /Users/michal/pudr.com/nuudel-to-ics/node_modules/.pnpm/object-inspect@1.13.4/node_modules/object-inspect/util.inspect

    node_modules/.pnpm/object-inspect@1.13.4/node_modules/object-inspect/index.js:54:26:
      54 │ var utilInspect = require('./util.inspect');
         ╵                           ~~~~~~~~~~~~~~~~

9:45:44 AM [vite] (client) error while updating dependencies:
Error: Build failed with 1 error:
node_modules/.pnpm/object-inspect@1.13.4/node_modules/object-inspect/index.js:54:26: ERROR: Cannot read file: /Users/michal/pudr.com/nuudel-to-ics/node_modules/.pnpm/object-inspect@1.13.4/node_modules/object-inspect/util.inspect
    at failureErrorWithLog (/Users/michal/pudr.com/nuudel-to-ics/node_modules/.pnpm/esbuild@0.25.1/node_modules/esbuild/lib/main.js:1477:15)
    at /Users/michal/pudr.com/nuudel-to-ics/node_modules/.pnpm/esbuild@0.25.1/node_modules/esbuild/lib/main.js:946:25
    at /Users/michal/pudr.com/nuudel-to-ics/node_modules/.pnpm/esbuild@0.25.1/node_modules/esbuild/lib/main.js:1355:9
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)

So now the issue is actually about ✘ [ERROR] Cannot read file: /Users/michal/pudr.com/nuudel-to-ics/node_modules/.pnpm/object-inspect@1.13.4/node_modules/object-inspect/util.inspect resp. the package object-inspect itself. And the advice I got is to exclude it from optimisations

So that's what I did by adding few lines to vite.config.mjs:

// vite.config.mjs

export default defineConfig({
  optimizeDeps: {
    exclude: ['object-inspect'],
  },
});

And since then the app builds and I seem to never get this error.

How to disable ember/no-empty-glimmer-component-classes

Michal Bryxí — Sat, 29 Mar 2025 12:46:47 +0000

Well technically in any *.js/*.ts file, but my 🧠 just got stuck on "this has to be part of ember-template-lint config", because I've seen a component that is basically just HTML.

At the end of the day, the linter rule is about JavaScript classes.

So if anyone bumps into this, the answer is NOT to put the config in .template-lintrc.js, but to eslint.config.mjs (or equivalent), in following way:

// eslint.config.mjs

export default ts.config(
  {
    files: ['**/*.{ts,gts}'],
    languageOptions: {
      parser: ember.parser,
      parserOptions: parserOptions.esm.ts,
    },
    extends: [...ts.configs.recommendedTypeChecked, ember.configs.gts],
    rules: {
      'ember/no-empty-glimmer-component-classes': 'off',
    },
  },
);

ResponsiveImage & EmberJS & glob vite imports

Michal Bryxí — Fri, 07 Mar 2025 10:08:18 +0000

ResponsiveImage is a:

Multi-framework JavaScript library for responsive images. Responsive images made easy.

embroider-build/app-blueprint is a:

Very experimental blueprint for scaffolding Ember v2 apps with Vite.

I had a need to dynamically load a folder images in my EmberJS app that is using embroider-build/app-blueprint and ResponsiveImage. Turns out I could use vite glob imports and resulting code looked something like:

import Component from '@glimmer/component';
import { ResponsiveImage } from '@responsive-image/ember';

const images = Object.values(
  import.meta.glob('/src/photos/*.jpg', {
    eager: true,
    query: '?lqip=inline&widths=1920,1280,640&responsive',
    import: 'default',
  }),
);

export default class MyComponent extends Component {
  <template>
    {{#each images as |image|}}
        <ResponsiveImage
          @src={{image}}
        />
    {{/each}}
  </template>
}

How I Manage Node & Package Manager Versions in 2025

Michal Bryxí — Thu, 23 Jan 2025 06:53:03 +0000

Some time has passed since I wrote How I Manage Node & Package Manager Versions in 2024 and few things have changed. So let's see what has changed and what are still goals:

Things works seamlessly. I switch projects = correct (versions) of tools are automatically used.
Minimal process to setup new projects is needed.
Local development environment and CI use the same ways to ensure consistency.

My stack of choice is node and pnpm, but this should work for most commonly used tools.

In the past I've used nvm, n, volta, corepack, nodeenv. While they all have their own strength, I converged to using proto as the tool of choice.

Installation

If possible, remove all previously versions of node or pnpm to make sure no conflicts occur.
Install proto:

> brew install proto
> proto setup

Project setup

Once you're in your my-app directory, run:

> proto pin node 20.18.0
> proto pin pnpm 9.14.2

It will create my-app/.prototools file with equivalent content, which can be commited to the repo to ensure that every single machine uses the same tool versions when running my-app:

node = "20.18.0"
pnpm = "9.14.2"

And this setup will be automatically honoured every time you run node or pnpm commands inside your project directory:

> node --version
v20.18.0

> pnpm --version
9.14.2

Unlocking your SSH key through OSX keychain

Michal Bryxí — Fri, 08 Nov 2024 19:02:15 +0000

The problem

Using passphrases for SSH keys is a very good idea, but since UX is inherent part of security I would advise on adding your SSH key to the ssh-agent to prevent password re-type fatigue & mishaps.

The solution

Follow along the documents above or try this shortened version:

Add following line to your ~/.zshrc:

ssh-add --apple-use-keychain ~/.ssh/id_rsa 2> /dev/null

Add following lines to yours ~/.ssh/config:

Host *
    UseKeychain yes
    AddKeysToAgent yes
    IdentityFile ~/.ssh/id_rsa

Microsoft 365 Outlook calendar in Todoist

Michal Bryxí — Fri, 08 Nov 2024 13:14:00 +0000

The problem

At the time of writing this article, one can connect only one calendar provided by only one company (Google) to Todoist. So if you want to connect Microsoft 365 Outlook calendar or second Google Calendar, you're out of luck.

There is, however, a trick that one can use to make both of the cases above work.

The solution

Prerequisites

First make sure that one of your Google Calendars is connected to your Todoist account. We will call it a Primary Google Calendar.

For Microsoft 365 Outlook

In Microsoft 365 Outlook find the calendar you want to share, and select Sharing and permissions:
Send the invite to your Primary Google Calendar account:
After that you will receive an email inviting you to said calendar. Click on Accept and view calendar button.
New page opens and you should see Add calendar modal. When you select Subscribe from web you should be able to see an input box with webcal://... URI. This will be your New Calendar in next steps.
As described in the use a link to add a public calendar documentation one has to: Open Primary Google Calendar and then on the left, next to Other calendars, click on the little + symbol and then select From URL:
Fill in your New Calendar URI into the From URL input box and hit Add calendar.

For 2nd Google Calendar

Following the ask to subscribe to calendar help page make sure that your 2nd calendar is shared to your Primary Google Calendar. This will be your New Calendar in next steps.

Displaying New Calendar in your Todoist

Open Settings -> Calendars -> Show events in Todoist.
Find your New Calendar and toggle the little eye icon on the right.
After this you should be able to see your New Calendar in Todoist:

OSX Sequoia & Operation not permitted (os error 1)

Michal Bryxí — Fri, 01 Nov 2024 15:52:00 +0000

With new, granular set of permission rights comes ... a bit of pain.

The problem

After upgrading to OSX Sequoia my terminal of choice - Warp started having weird seemingly permission-like issues. Even simple operations like ls sometimes failed with Operation not permitted (os error 1):

ls /Volumes/BACKUP/
"/Volumes/BACKUP/": Operation not permitted (os error 1)

But other apps like Finder had no problem accessing said folder.

The solution

Eventually I noticed that the issue happened always when I tried to access data on an USB thumb drive. Remembering that apps in newer OSX do not have permission to just access disk willy nilly, I opened: System Settings -> Privacy & Security -> Full Disk Access, changed the toggle for Warp to enabled and let the app reboot. And voila! Now it works again.

Installing EmberJS v2 addons from GitHub forks using PNPM

Michal Bryxí — Mon, 16 Sep 2024 11:54:27 +0000

The problem

If you're using PNPM as a package manager for your EmberJS project and you find yourself in a need to install a v2 addon from git(hub) fork (because you have a branch with patched version), then you might find that GitHub URLs in package.json tricks don't work for you.

The analysis

Reason for this is because v2 addons are a monorepo and we're still in the phase where pretty much every tool out there lacks good support/DX for monorepos.

There are different possible solutions for different cases:

gitpkg.vercel.app - Using sub folders of a repo as yarn/npm dependencies made easy.
pnpm patch - Prepare a package for patching
patch-package - Lets app authors instantly make and keep fixes to npm dependencies.

But if you happen to use PNPM in your project you might get away with providing a customised git URL.

The solution

Let's assume I have a patch branch of ember-highcharts that has latest commit of SHA: 7995a3e7d2203ce174c39e186acc9257d883bf61. The web URL is:

https://github.com/MichalBryxi/ember-highcharts/tree/7995a3e7d2203ce174c39e186acc9257d883bf61

I can add this patched fork to my project as follows:

pnpm add -D 'github:MichalBryxi/ember-highcharts#7995a3e7d2203ce174c39e186acc9257d883bf61&path:ember-highcharts'

Where:

github: Shorthand for pnpm to know where the code is hosted
MichalBryxi - My github namespace
ember-highcharts - Name of the repo (my fork)
7995a3e7d2203ce174c39e186acc9257d883bf61 - respective commit that contains the patch I'm interested in
path:ember-highcharts - In this v2 addon the ember-highcharts subdirectory contains the code for the addon

Conclusion

With PNPM it is possible to install EmberJS v2 addons, or any other packages living in monorepos, from GitHub forks.

Google Photos & undismissable notification in Utilities

Michal Bryxí — Wed, 11 Sep 2024 12:01:23 +0000

There are few things more frustrating than misbehaving tech with easy to reproduce bugs that, for some reason, are ignored for years.

One of those for me is Google Photos "Utilities notification" that simply keeps re-appearing cards with automated creations that I dismissed twenty times before.

If you have the same issue, then you can pop open developer tools console (command + option i) and paste following code there:

$$('[aria-label="Dismiss"]').forEach(element => element.click());

This will find all the "dismiss" buttons on all the cards and press them. You will probably need to do few full page reloads and repeat the command, as Google Photos is even bad at the "infinite scrolling" load implementation, but this alone should save you few dozens of clicks.

How I Manage Node & Package Manager Versions in 2024

Michal Bryxí — Fri, 06 Sep 2024 06:11:23 +0000

The problem

On OSX, when it comes to managing version of things in NodeJS world, there are many options nvm, n, nodenv, volta, homebrew for NodeJS management and other heap for package manager versions.

This process in this article tries to achieve only those things:

Things works seamlessly. I switch projects, correct (versions) of tools are automatically used.
Minimal process to setup new projects is needed.
Local development environment and CI both use the same ways to ensure consistency.

NodeJS version management

Homebrew

No. Although it's super fast, reliable and stable, you will very quickly run into many problems:

One project needs version A, while other needs version B.
Your local environment uses A, while CI uses B.
Switching versions is manual, slow and costly.

nvm, n, nodenv, ...

Maybe. I don't have anything against any of those projects. I just happened to land on the next one. Might work for you just ok.

volta

Yes. The nice thing about volta is that it's super fast to install, works reliably and lets you know when something is :sus:.

Package manager version management

Corepack

No. Corepack is natively present in Node since version 16.9.0, so more recent systems you won't have to do too much. But as per this blogpost on socket.dev and this pull request in node corepack is likely to be removed from node and additional steps will be necessary to install it.

volta

Yes. My package manager of choice pnpm is partially supported, so with a little bit of (temporary) configuration, this is a perfect solution. Also we have to use only one tool for managing node and package manager versions..

The solution

Prepare

You will need to do these steps only once.

If you want to follow along, first, you'd want to remove all the other tools you might have installed as there is high chance that they will interfere with your new stack:

brew uninstall pnpm # do not use brew to manage pnpm
brew uninstall node # do not use brew to manage node
brew uninstall nvm # do not use nvm/n/nodenv/...
corepack disable # do not use corepack

Then we will install volta (I will copy&paste below, but better if you just follow the official guide):

curl https://get.volta.sh | bash

volta install node

Now to enable PNPM support in Volta you will need to add VOLTA_FEATURE_PNPM=1 to your environment variables. If you're using zsh like me, you might want to add it in following way:

# ~/.zshenv
export VOLTA_FEATURE_PNPM=1 # Your new line
export VOLTA_HOME="$HOME/.volta" # Already added by volta installation
export PATH="$VOLTA_HOME/bin:$PATH" #Already added by volta installation

At this point most of the manuals will tell you to start a new shell. To prevent stepping on a rake, I would recommend doing a quick system reboot. I think it's worth the little wait.

Project modifications

Ton pin down the versions in your project use volta pin command in directory of your package.json:

volta pin node@18
volta pin pnpm@9.9.0

GitLab CI

I battled a bit with GitLab CI to make this work nicely, but following should work for you:

# .gitlab-ci.yml
image: node:18

before_script:
  # There is an ugly catch-22 situation that GitLab CI
  # does not have a good way to modify all the needed
  # environment variables in the correct way
  # and at the right time, so this will have to do.
  - source .gitlab-ci-env.sh

stages:
  - build
  - test

cache:
  paths:
    # Make sure to persist our volta installation 
    # between individual stages.
    - .volta
install_dependencies:
  stage: build
  script:
    - apt-get update
    - apt-get install -y curl
    - curl https://get.volta.sh | bash
    - pnpm install

testing_testing:
  stage: test
  script:
    - pnpm test

And then put this file next to .gitlab-ci.yml:

# .gitlab-ci-env.sh

# Enable support for PNPM
export VOLTA_FEATURE_PNPM=1

# We want volta to be installed into our project dir,
# otherwise GitLab won't be able to cache it.
export VOLTA_HOME="$CI_PROJECT_DIR/.volta"

# Adjust $PATH so we can call volta executable.
export PATH="$VOLTA_HOME/bin:$PATH"

Conclusion

There are many ways to do version management. I think that this one is the simplest, while allowing the greatest level of flexibility. But happy to adjust the article (already did :)) if someone shows me a better way.