profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/buschtoens/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Jan Buschtöns buschtoens @ClarkSource Frankfurt am Main, Germany https://jan.buschtoens.me $ npx buschtoens

adopted-ember-addons/ember-light-table 311

Lightweight, contextual component based table for Ember 2.3+

alphasights/ember-scrollable 23

A simple Ember wrapper around Trackpad Scroll Emulator

buschtoens/acme-v2 15

ACME v2 client written in Node.js for retrieving free SSL / TLS certificates

buschtoens/combine-type-predicates 6

Combine user-defined type guards / type predicates as unions and intersections.

buschtoens/broccoli-flatiron 1

Flatten directory structures to a single ES6 JSON module

buschtoens/buschtoens-cli 1

@buschtoens in your terminal!

alexander-alvarez/ember-light-table 0

Lightweight, contextual component based table for Ember 2.3+

buschtoens/ahoy.js 0

Simple, powerful JavaScript analytics

issue commentionic-team/capacitor

Investigate multiple environment support

@jayenashar I think the idea is to export different configs from a single capacitor.config.{js,ts} file. You could for instance look at process.env to dynamically generate the right config.

imhoffd

comment created time in 12 days

pull request commentjchafik/google-search-shortcuts

fix: update `visibleResultsQuerySelector`

<sup>I hate bumping, but</sup> @jchafik did you maybe have chance to look at this? :)

The addon is unfortunately still broken for me, but this PR would fix it. At least, the last time I checked. 😄

buschtoens

comment created time in 12 days

issue commentjchafik/google-search-shortcuts

Pressing TAB jumps multiple results at a time

@Newgap Nope. The PR is stil not merged, so it's unfortunately also not in the latest release.

bb2020

comment created time in 12 days

create barnchbuschtoens/ember-survey

branch : gh-pages

created branch time in 12 days

pull request commentionic-team/capacitor

feat(cli): allow async `capacitor.config.{ts,js}`

Another, possibly more standard / intuitive, option is using top-level await.

// capacitor.config.ts
import type { CapacitorConfig } from '@capacitor/cli';

const appId = await determineAppId();

const config: CapacitorConfig = {
  appId,
  appName: 'My Capacitor App',
  // ...
};

export default config;
buschtoens

comment created time in 20 days

issue openedember-cli/ember-try

`pnpm` or generic package manager support

Currently ember-try only supports two package managers for installing node_modules:

  • npm: the default
  • yarn (v1.x): if the user opts-in by setting useYarn: true
  • (bower: technically supported in parallel, however it's deprecated since #402, basically dead 🧟, and doesn't actually manage node_modules.)

yarn v1.x is discontinued in favor of v3.x (dubbed berry). Unfortunately, the berry CLI and the new PnP package format is largely incompatible with ember-cli and ember-try. Related issues:

  • #741
  • #214

I doubt, that adopting berry will be easy or possible at all for the Ember ecosystem.

However by now, there are further actively maintained alternatives to choose from. For instance, there's:

  • pnpm: an alternative package manager, with a feature set similar to yarn, but better performance and disk efficiency.
  • rush: a monorepo (build) manager, similar to lerna, that wraps around the underlying package manager, currently supporting npm, pnpm & yarn.

I would love to start using pnpm for various reasons.

The main issue isn't the resulting node_modules structure, which luckily appears to be compatible with or eaasy to adapt to for ember-cli projects, at least in my limited experience thus far. The deal breaker currently is the implicit ecosystem-wide assumption that either npm or yarn are being used.

There is an effort to fix that for ember install (https://github.com/ember-cli/ember-cli/pull/9563), but npm / yarn are used explicitly in the wider ecosystem as well, like here in ember-try.

I got nerd-sniped and am happy to report that I was able to monkey-patch ember-try with the following snippet to make it use pnpm:

const NPMDependencyManagerAdapter = require('ember-try/lib/dependency-manager-adapters/npm');

// Maps arguments for `yarn` to their `pnpm` equivalents. A falsy value, like
// `undefined`, means that the argument is not supported by `pnpm` and will be
// dropped.
// https://github.com/ember-cli/ember-try/blob/v1.4.0/lib/dependency-manager-adapters/npm.js#L116-L123
const argsMap = {
  // > Don't read or generate a `yarn.lock` lockfile.
  // https://classic.yarnpkg.com/en/docs/cli/install/#toc-yarn-install-no-lockfile
  //
  // Normally we would enable `--frozen-lockfile`, however:
  // > If `true`, pnpm doesn't generate a lockfile and fails to install if the
  // > lockfile is out of sync with the manifest / an update is needed or no
  // > lockfile is present.
  // https://pnpm.io/cli/install#--frozen-lockfile
  //
  // Instead we use:
  // > When set to `false`, pnpm won't read or generate a `pnpm-lock.yaml` file.
  // https://pnpm.io/npmrc#lockfile
  '--no-lockfile': '--config.lockfile=false',

  // > Ignore engines check.
  // https://classic.yarnpkg.com/en/docs/cli/install/#toc-yarn-install-ignore-engines
  //
  // > During local development, pnpm will always fail with an error message, if
  // > its version does not match the one specified in the engines field.
  // >
  // > Unless the user has set the `engine-strict` config flag (see `.npmrc`),
  // > this field is advisory only and will only produce warnings when your
  // > package is installed as a dependency.
  // https://pnpm.io/package_json#engines
  //
  // ! This probably doesn't work as expected, because of the "during local
  // development" limitation.
  '--ignore-engines': '--config.engine-strict=false',
};

// Override the `init` method (= "`constructor`") of the `ember-try` dependency
// manager adapter for `npm`, so that `pnpm` support can be optionally enabled
// by setting `npmOptions: { manager: 'pnpm' }` in the `config/ember-try.js`.
//
// https://github.com/ember-cli/ember-try/blob/v1.4.0/lib/dependency-manager-adapters/npm.js#L13-L16
const originalInit = NPMDependencyManagerAdapter.prototype.init;
NPMDependencyManagerAdapter.prototype.init = function (...args) {
  originalInit.apply(this, args);

  // If `npmOptions.manager` is set to `"pnpm"`, then enable `pnpm` mode.
  //
  // `npmOptions` is passed in as `managerOptions`.
  // https://github.com/ember-cli/ember-try/blob/v1.4.0/lib/utils/dependency-manager-adapter-factory.js#L39
  if (this.managerOptions?.manager === 'pnpm') {
    // If `npmOptions` is an object with an `args` property, then let `args`
    // take the place of `managerOptions`, so that the upstream code can process
    // it.
    if (this.managerOptions.args instanceof Array)
      this.managerOptions = this.managerOptions.args;
    // If `npmOptions` itself already is an array (with an extra `manager`
    // property), then keep it as-is, so that the upstream code can process it.
    // If it isn't an array, and `args` is also not set, then unset
    // `managerOptions`, as `npmOptions` was only used to opt-in to `pnpm` mode.
    else if (!(this.managerOptions instanceof Array))
      this.managerOptions = undefined;

    // Enable the `yarn` code path, which is close to what we need for `pnpm`.
    this.useYarnCommand = true;

    // Substitute `yarn.lock` with `pnpm-lock.yaml` accordingly.
    this.yarnLock = 'pnpm-lock.yaml';

    // Note: the upstream convention is to append `.ember-try` _after_ the file
    // extension, however this breaks syntax highlighting, so I've chosen to
    // insert it right before the file extension.
    this.yarnLockBackupFileName = 'pnpm-lock.ember-try.yaml';

    // Patch the `run` method to replace `yarn` with `pnpm` and translate &
    // filter the arguments accordingly.
    const originalRun = this.run;
    this.run = (_cmd, args, opts) =>
      originalRun.call(
        this,
        'pnpm',
        args
          .map((arg) => (arg in argsMap ? argsMap[arg] : arg))
          .filter(Boolean),
        opts
      );
  }
};

I keep this file in an extra directory that is .npmignore'd and import it in config/ember-try.js like so:

const getChannelURL = require('ember-source-channel-url');
const { embroiderSafe, embroiderOptimized } = require('@embroider/test-setup');

try {
  require('../patches/ember-try');
} catch {
  console.warn('Failed to patch `ember-try` for `pnpm` support.');
}

module.exports = async function () {
  return {
    npmOptions: {
      manager: 'pnpm',
      args: ['--prefer-offline'],
    },

    scenarios: [ /* ... */ ]
  }
};

It's not perfect, but it works. 🥳

I would be more than happy to PR this, so that ember-try can officially / experimentally support pnpm. The necessary underlying code changes aren't too drastic, but I'm not entirely sure regarding:

  • What the official user-facing API should look like; useYarn + usePnpm doesn't really make sense and means that we'll keep having this issue, when the next package manager / wrapper comes along.
  • Whether this might be a good opportunity to refactor the internal API, so that it becomes more flexible and might even allow users to provide their own adapters.

What are your thoughts on this?

created time in 21 days

Pull request review commentmicrosoft/TypeScript

Migrate latest dom types into libdom.d.ts

 declare var SVGElement: {     new(): SVGElement; }; -interface SVGElementInstance extends EventTarget {-    readonly correspondingElement: SVGElement;-    readonly correspondingUseElement: SVGUseElement;-}

Removal was intentional, as per https://github.com/microsoft/TypeScript-DOM-lib-generator/issues/1023#issuecomment-908524091:

Those are not available on any modern browser nor MDN, and thus are probably IE-specific properties. The removal is intended since the types library intends to only include things that exist in modern browsers.

orta

comment created time in 21 days

PullRequestReviewEvent

Pull request review commentmicrosoft/TypeScript

Update LKG to enable improved narrowing in 4.4.

 declare var SVGElement: {     new(): SVGElement; }; -interface SVGElementInstance extends EventTarget {-    readonly correspondingElement: SVGElement;-    readonly correspondingUseElement: SVGUseElement;-}

Removal was intentionalm, as per https://github.com/microsoft/TypeScript-DOM-lib-generator/issues/1023#issuecomment-908524091:

Those are not available on any modern browser nor MDN, and thus are probably IE-specific properties. The removal is intended since the types library intends to only include things that exist in modern browsers.

DanielRosenwasser

comment created time in 21 days

PullRequestReviewEvent

issue commentmicrosoft/TypeScript-DOM-lib-generator

DOM Lib Generator infra thread

@saschanaz Thank you for your quick response and explanation!

That makes sense. I was unable to find proper docs for these properties as well, except for the discontinued WebPlatform project.

I guess keeping them removed is most sensible. :+1:

orta

comment created time in 21 days

issue commentmicrosoft/TypeScript-DOM-lib-generator

DOM Lib Generator infra thread

Congratulations on this huge achievement!

Is this the right place to report issues?

I've noticed that the correspondingElement & correspondingUseElement properties have been removed from SVGElement with these PRs:

  • https://github.com/microsoft/TypeScript/pull/44684/#discussion_r698656848
  • https://github.com/microsoft/TypeScript/pull/44842/#discussion_r698656080

Was the removal intentional? Should they be reintroduced?

orta

comment created time in 21 days

Pull request review commentmicrosoft/TypeScript

Migrate latest dom types into libdom.d.ts

 declare var SVGElement: {     new(): SVGElement; }; -interface SVGElementInstance extends EventTarget {-    readonly correspondingElement: SVGElement;-    readonly correspondingUseElement: SVGUseElement;-}

These properties used to be available on SVGElement, which used to extend SVGElementInstance in LOC 12883. They disappeared during the upgrade from v4.3.5 to v4.4.2.

orta

comment created time in 21 days

PullRequestReviewEvent

Pull request review commentmicrosoft/TypeScript

Update LKG to enable improved narrowing in 4.4.

 declare var SVGElement: {     new(): SVGElement; }; -interface SVGElementInstance extends EventTarget {-    readonly correspondingElement: SVGElement;-    readonly correspondingUseElement: SVGUseElement;-}

These properties used to be available on SVGElement, which used to extend SVGElementInstance in LOC 12903. They disappeared during the upgrade from v4.3.5 to v4.4.2.

DanielRosenwasser

comment created time in 21 days

PullRequestReviewEvent

issue commentwillviles/ember-useragent

Remove automatic injections

@snewcomer perfect, thanks! I wasn't sure any more and didn't re-read.

buschtoens

comment created time in a month

Pull request review commentwillviles/ember-useragent

feat: removes auto injection of userAgent service

 import UAParser from 'ua-parser-js';  ### Injection -By default, this addon will generate an initializer in `app/initializers/user-agent.js` that injects the `userAgent` service app-wide. If the `userAgent` property conflicts with other addons or you wish to use manual injection (`Ember.service.inject`) you can override this file.+Prior to `0.11.0`, this addon generated an initializer in `app/initializers/user-agent.js` that injected the `userAgent` service across all controllers, components and routes. This does not happen in `>=0.11.0`.

You could include something like the following in the PR body:

Ember v4.0 removes support for implicit inejctions, as perf https://github.com/emberjs/ember.js/pull/19680. If you were relying on this feature in your code, you should migrate your code base and explicitly inject the userAgent service at the call sites.

If you absolutely must temporarily restore the old behavior, you can include this intializer as app/intializers/user-agent.js:

https://github.com/willviles/ember-useragent/blob/32039b648e3e0eb18f99b5db74d9ce9dcfd4abfa/addon/initializers/user-agent.js#L7-L14

Please note, that you will still have to migrate your app to use explicit injections, in order to be able to upgrade to Ember v4.0, so this should only be used as a last-resort temporary band-aid.

willviles

comment created time in a month

PullRequestReviewEvent

Pull request review commentwillviles/ember-useragent

feat: removes auto injection of userAgent service

 import UAParser from 'ua-parser-js';  ### Injection -By default, this addon will generate an initializer in `app/initializers/user-agent.js` that injects the `userAgent` service app-wide. If the `userAgent` property conflicts with other addons or you wish to use manual injection (`Ember.service.inject`) you can override this file.+Prior to `0.11.0`, this addon generated an initializer in `app/initializers/user-agent.js` that injected the `userAgent` service across all controllers, components and routes. This does not happen in `>=0.11.0`.
Prior to `0.11.0`, this addon generated an initializer in `app/initializers/user-agent.js` that injected the `userAgent` service across all controllers, components and routes. This does not happen in `>=0.11.0`.

You can restore this behavior by manually performing these implicit injections (see [#42](https://github.com/willviles/ember-useragent/pull/42)), however this is highly discouraged, as this feature is deprecated by the upcoming Ember `v4.0`. If you were relying on these implicit injections, you should instead refactor your code to explicitly inject the `userAgent` service.
willviles

comment created time in a month

PullRequestReviewEvent

issue commentwillviles/ember-useragent

Remove automatic injections

As a way forward for ember-useragent itself, I would recommend to replace the application.inject(...) usages with custom macros, that raise a deprecation, when accessed.

Optionally configuration could be included, to completely disable the injection, which should be recommended to be enabled by all new users. This way the breaking release can be delayed indefinitely, all the while being ready for Ember 4.0.

buschtoens

comment created time in a month

issue commentwillviles/ember-useragent

Remove automatic injections

It is unquestionable, that these implicit injections will have to be removed eventually due to https://github.com/emberjs/ember.js/pull/19680. Thus I recommend that anyone wanting to or currently using this addon, overrides https://github.com/willviles/ember-useragent/blob/master/app/initializers/user-agent.js in their own app with a no-op, like:

// app/initializers/user-agent.js
export function initialize() {}

This way the implicit injections are already disabled and you can't accidentally make use of them. Please note, that if you're making this change in an app that already uses ember-useragent, you should regression test it to ensure, you haven't already used these implicit injections accidentally.

buschtoens

comment created time in a month

startedjpochyla/psst

started time in a month

startedblakeblackshear/frigate

started time in a month

PR opened swc-project/jest

fix(deps): `pperDependencies` -> `peerDependencies`
+1 -1

0 comment

1 changed file

pr created time in a month

push eventbuschtoens/jest-1

Jan Buschtöns

commit sha b7e39e226278614a677f70d1643c50bf6abfe38b

fix(deps): `pperDependencies` -> `peerDependencies`

view details

push time in a month

fork buschtoens/jest-1

Super-fast alternative for babel-jest or ts-jest without type checking

fork in a month

issue commentswc-project/jest

No way to override jsc or module swc configuration?

Much appreciated! Thank you. 💖

What do you think a good long-term plan would be for the config patching? AFAICT, these options are crucial when wanting to use TypeScript & ESM with jest:

{
  "sourceMaps": true,         // Important
  "jsc": {
    "parser": {
      "syntax": "typescript", // Important
      "tsx": true,            // Depending on whether `.tsx` is targeted as well.
      // "decorators": false,
      "dynamicImport": true   // Important.
    },
    "target": "es2020"        // I think that was important for dynamic import stuff.
  },
  "module": null              // Important
}
{
  transform: {
    '^.+\\.tsx?$': '@swc/jest'
  },
  extensionsToTreatAsEsm: ['.ts', '.tsx']
}

It would be nice, if these options could eventually be applied correctly out-of-the-box.

dbjorge

comment created time in a month