profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/jamiebuilds/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.

fabiospampinato/cash 5295

An absurdly small jQuery alternative for modern browsers.

gaearon/react-transform-boilerplate 3417

A new Webpack boilerplate with hot reloading React components, and error handling on module and component level.

amilajack/eslint-plugin-compat 2720

Lint the browser compatibility of your code

boltpkg/bolt 2090

⚡️ Super-powered JavaScript project management

gaearon/babel-plugin-react-transform 1094

Babel plugin to instrument React components with custom transforms

gaearon/react-transform-hmr 789

A React Transform that enables hot reloading React classes using Hot Module Replacement API

avajs/ava-docs 468

Localized docs for AVA

babel-utils/babel-plugin-tester 245

Utilities for testing babel plugins

gaearon/react-transform-catch-errors 185

React Transform that catches errors inside React components

babel-utils/ast-pretty-print 128

A pretty printer for AST-like structures

push eventrome/tools

Jamie Kyle

commit sha f162690c107a93d0514b59a69e3f3de003a56104

Begin migration to Rust codebase

view details

push time in a day

create barnchrome/tools

branch : rust

created branch time in a day

issue commenttc39/proposal-pipeline-operator

Bikeshedding the Hack topic token

Generally if you are working in expression-space, you aren't giving intermediate values names:

numbers.filter(isEven).map(double)
// or 
map(filter(numbers, isEven), double)
// or (soon)
numbers |> filter(^, isEven) |> map(^, double)

So I don't find it particularly important that people be able to give names to intermediate values.

js-choi

comment created time in 4 days

push eventjamiebuilds/codeowners-enforcer

Ben Limmer

commit sha e3bf9651f3f942e3ca952db8525bce93a69c7090

fix: enable enforcement for hidden files and directories

view details

Ben Limmer

commit sha cb32f0f219e2a1727c5fe3545a3736d1bbc1f111

fix: use macOS 10.14 vs. 10.13

view details

Jamie Kyle

commit sha 125beb912396035ffb79c94169cc5c63c9474667

Merge pull request #9 from blimmer/fix/support-hidden-files fix: enable enforcement for hidden files and directories

view details

push time in 4 days

PR merged jamiebuilds/codeowners-enforcer

Reviewers
fix: enable enforcement for hidden files and directories

Thank you for this awesome CLI tool, it really made enforcing codeowners quite easy for me!

The one issue I ran into is that hidden files/directories are not currently supported by the tool. So, for instance, if I want to enforce ownership of all GitHub actions in a repository (e.g. .github/workflows), it's currently not possible.

With this changeset, however, hidden files are now included.

For others interested in this change, I published the assets produced by the Azure pipeline build over on my fork: https://github.com/blimmer/codeowners-enforcer/releases/tag/v1.0.4 . I verified it was working on this test PR: https://github.com/blimmer/ensure-codeowners-demo/pull/7

+5 -1

0 comment

2 changed files

blimmer

pr closed time in 4 days

issue commentbathos/proposal-string-cooked

Cooking raw literalSegments?

I guess the question is more, String.raw({ raw: ["foo", "bar"] }, []) works because there's no validation to ensure the inputs come from a template string, should String.cooked({ raw: ["foo", "bar"] }, []) have defined behavior?

hemanth

comment created time in 5 days

issue commenttc39/proposal-pipeline-operator

Hack-pipe placeholder bikeshedding

Well, I'm not sure if we start designing around third party tools that there will ever be a symbol that isn't a problem. I've certainly see % used for plenty of templating languages that get used to generate JavaScript code. I think more and more it comes down to an aesthetic/design choice.

js-choi

comment created time in 5 days

issue commenttc39/proposal-pipeline-operator

Hack-pipe placeholder bikeshedding

I noted software-based keyboards in the next section.

js-choi

comment created time in 5 days

issue commenttc39/proposal-pipeline-operator

Hack-pipe placeholder bikeshedding

Viability investigation of keyboard-usability ^ as topic variable

Background

This proposal was updated some days ago to use the ^ token as the topic variable. However, it was soon pointed out that in several European keyboards it is difficult to type ^ due to it being a "dead key" for typing diacritics like âêîôû.

Typing a diacritic using dead keys works in two steps:

  1. Type <kbd>Shift+^`
  2. Type <kbd>a</kbd>, <kbd>e</kbd>, <kbd>i</kbd>, <kbd>o</kbd>, or <kbd>u</kbd>.

If you want to type ^, you have a similar two steps:

  1. Type <kbd>Shift+^</kbd>
  2. Type <kbd>Space</kbd>

Importantly: If you type any other key after <kbd>Shift+^</kbd>, such as <kbd>g</kbd>, you will get ^g.

<div> </div>

Initially this seemed like it should kill ^ as a token. But after further investigation I've found this issue both partially mitigated by how it appears in syntax, and in comparison to other symbols that appear in the language.


❌ "You should switch to a US-keyboard"

I did hear from a lot of developers that their non-US keyboard caused them so much frustration that they switched to US-keyboards.

While that certainly solves the problem, that should not be our answer for people that say ^ is hard to type.

We should not say the burden is on the developer for not purchasing a new keyboard.


❌ "You should edit ${some system configuration}"

There are a number of ways that developers could make symbols like ^ easier for them to type. You can disable it as a dead key. You can make another key output ^. You can even switch to a US-keyboard layout at a software level.

These also would solve the problem, but in unfortunate ways. Realistically, many or most developers will never do any of that. It's generally not a simple system configuration change, and most of those solutions create a mismatch between what is on the physical keyboard and what is written to the screen. Sometimes you also have to purchase third party software.

We should not say the burden is on the developer for not changing system configuration or purchasing software.


❌ *️⃣ "Code editors can fix the issue"

In theory (I don't know practically how difficult it would be), code editors could detect ^ being used as a dead key and insert ^ and exit dead key mode. This could even be semantically-aware of its surrounding syntax (i.e. "Are we in a string or comment?").

*️⃣ This actually might be a decent idea for code editors. I hope that someone investigates this further. But:

We should not say the burden is on the developer using a particular code editor


❌ "Other symbols are also hard to type"

For the purpose of searching for alternatives to ^ I asked developers what were the hardest keys on their keyboard to type. It turns out that many common characters are difficult to type. &, ^, ~, `, [, ], {, and } are all difficult on a number of different keyboards. All of which exist in JavaScript syntax (some more frequently than others) today.

<details>

<summary><strong>See results of polling</strong></summary>

char count visual notes
& 4 ####
^ 10 ########## Swedish: Dead Key, German: Typing vowels after becomes â
$ 3 ###
@ 3 ###
# 4 ####
! 1 #
? 2 ##
~ 5 ##### Swedish: Dead Key
` | 9 | ######### | German: Typing vowels after becomes á
' 1 #
" 1 #
( 3 ###
) 3 ###
[ 6 ###### Swedish/French: AltGr
] 6 ###### Swedish/French: AltGr
{ 7 ####### Swedish/French: AltGr
} 7 ####### Swedish/French: AltGr
< 3 ###
> 3 ###
, 1 #
. 1 #
; 2 ##
: 2 ##
+ 1 #
- 1 #
* 1 #
/ 2 ##
% 2 ##
= 3 ###
_ 2 ##
\| 2 ##
\\ 3 ### Swedish: AltGr

</details>

^ does stand out as a particularly difficult character to type (as does ` but that ship has sailed). We should keep in mind these results when looking at other options for the topic token. But on its own


❌ "Non-latin-alphabet keyboards have already been left behind"

It's also important to note that beyond just US-keyboard symbols, JavaScript syntax (and the vast majority of programming languages) are already very latin-alphabet-centric. There are plenty of non-latin keyboards that would be extremely difficult to type JavaScript syntax with due to the use of latin-alphabet characters throughout the syntax (symbols actually tend to be easier to type on these keyboards).

<img src="https://user-images.githubusercontent.com/952783/133140248-528a238d-9d79-4131-b637-3e2a1bbf903f.png" width="300"/>

For these users, the only answer is to switch to a different (likely US) keyboard. Sadly I don't think there is ever going to be an answer for this, the subset of keys all keyboards can type is very small.

This still shouldn't be our answer though. Excluding some people should not be reason to exclude more people.

(Same reasoning as above)


✅ *️⃣ "^ as the token operator syntactically never has a, e, i, o, or u after it"

While ^ on its own is difficult to type, it's not so difficult when you consider its placement in the syntax. A reminder on the different combinations:

Typing a diacritic using dead keys works in two steps:

  1. Type <kbd>Shift+^`
  2. Type <kbd>a</kbd>, <kbd>e</kbd>, <kbd>i</kbd>, <kbd>o</kbd>, or <kbd>u</kbd>.

If you want to type ^, you have a similar two steps:

  1. Type <kbd>Shift+^</kbd>
  2. Type <kbd>Space</kbd>

Importantly: If you type any other key after <kbd>Shift+^</kbd>, such as <kbd>g</kbd>, you will get ^g.

The topic operator will never have a latin-alphabet character immediately following it.

x |> ^.y()
x |> y(^)
x |> ^+y
x |> ^ instanceof y
// etc...

The worst case scenario is when you have a <kbd>Space</kbd> immediately following the <kbd>^</kbd>, because it will require the developer to type <kbd>Space</kbd> twice. But that's not terrible.

Even when you consider future syntax, any latin-alphabet character following ^ would be a problem for the grammar anyways. Note how instanceof requires a preceding space for the grammar to work. The only possibility would be if we extended the topic variable syntax itself which is something we should be exploring now anyways.

*️⃣ This isn't a perfect answer. Developers will still enter dead key mode, but I think it's reasonable that they would just naturally pick up on being able to type as if they weren't in dead key mode.

We can safely rely on surrounding syntax to prevent ^ as the topic operator from ever causing them to accidentally create diacritics by typing valid JavaScript syntax.


Conclusion: ✅ ^ is okay to move forward with

Personally, after this investigation, I'm not as worried about ^ as the token choice for the topic operator anymore. I feel confident that we can promise the following character will never be a, e, i, o, or u in any future grammar, and I don't see a good reason to extend the topic operator to accept latin-alphabet characters after it. I do wish we could design a syntax that works effortlessly for everyone, but I don't think this is particularly problematic syntax that we can't move forward with it.

js-choi

comment created time in 5 days

PullRequestReviewEvent

issue commentbathos/proposal-string-cooked

Function signature bikeshed

it's an additional load on the call stack and the spread operator can be just forgotten.

I don't think it is particularly meaningful overhead that it should be specifically designed to prevent anyone from ever using it that way. And I don't think we should make things different for the sake of making them different.

jamiebuilds

comment created time in 9 days

issue commentbathos/proposal-string-cooked

Name bikeshed

Also to mention, I've seen a number of compilers in different languages use the term "cooked" to distinguish it from "raw". In Rome we use it like this:

jsTemplateElement.create({
  cooked: "",
  raw: "",
})
jamiebuilds

comment created time in 9 days

issue commentbathos/proposal-string-cooked

Name bikeshed

One downside for names like String.zip, String.interleave, possibly String.interpolate, and arguably String.identity is that their method names on their own are common names of much more generic functions in other languages (i.e. IterTools.interleave) / JS libraries (i.e. lodash.identity), and are names we may consider in the future for an IterTools JS proposal, or something else.

jamiebuilds

comment created time in 9 days

issue commenttc39/proposal-pipeline-operator

Hack-pipe placeholder bikeshedding

I asked on twitter which symbols are hardest to type. I didn't get a ton of responses, but I think it was clear which ones were most problematic.

char count visual notes
& 4 ####
^ 10 ########## Swedish: Dead Key, German: Typing vowels after becomes â
$ 3 ###
@ 3 ###
# 4 ####
! 1 #
? 2 ##
~ 5 ##### Swedish: Dead Key
"`" 9 ######### German: Typing vowels after becomes á
' 1 #
" 1 #
( 3 ###
) 3 ###
[ 6 ###### Swedish/French: AltGr
] 6 ###### Swedish/French: AltGr
{ 7 ####### Swedish/French: AltGr
} 7 ####### Swedish/French: AltGr
< 3 ###
> 3 ###
, 1 #
. 1 #
; 2 ##
: 2 ##
+ 1 #
- 1 #
* 1 #
/ 2 ##
% 2 ##
= 3 ###
_ 2 ##
\| 2 ##
\\ 3 ### Swedish: AltGr
js-choi

comment created time in 9 days

push eventtc39/agendas

Jamie Kyle

commit sha 40d7236bc74de9e104116968a8fd285f2ec85dd8

Add String.cooked to next meeting

view details

push time in 9 days

issue commentbathos/proposal-string-cooked

Tracking issue for TC39 process requirements

Working on a presentation to bring this proposal to the October meeting: https://docs.google.com/presentation/d/1Au8FP1xTuXb52d6kG1fxX5Cxl3J-02h3FAaq8tMEtn8/edit?usp=sharing

jamiebuilds

comment created time in 9 days

issue commentbathos/proposal-string-cooked

Prior discussion

@hax You could imagine Iterator#interleave/zip and Iterator#join methods that could be combined to make it easier to merge the strings and values arrays provided to template tags:

function myTag(strings, ...values) {
  return strings.values().interleave(values).join("")
}

An equivalent in Rust:

use itertools::Itertools;

fn main() {
    let strings = ["a", "b", "c"].iter();
    let values = ["1", "2"].iter();
    let result = strings.interleave(values).join("");    
    dbg!(res); // res = "a1b2c"
}
bathos

comment created time in 9 days

issue commenttc39/proposal-pipeline-operator

Optional Hackpipes proposal

I could see a use case for bailing out of pipeline early.

// pseudo-syntax
let value = a()
  |> ^ == null ? BAIL_KEYWORD : b(^)
  |> c(^)

I don't know if anything like that exists in other languages around pipelines or similar constructs.

webduvet

comment created time in 9 days

issue commenttc39/proposal-pipeline-operator

Text readability

I think this issue belongs in https://github.com/tc39/ecmarkup

bodograumann

comment created time in 9 days

issue commenttc39/proposal-pipeline-operator

Moving ahead with the minimal proposal

I'm going to ask that people communicate their concerns and criticisms of this proposal without making personal attacks. This was not the decision of a single person, the Hack-style pipelines proposal was presented at the last TC39 meeting and the committee reached consensus to moving to Stage 2.

pygy

comment created time in 9 days

Pull request review commentjamiebuilds/codeowners-enforcer

fix: enable enforcement for hidden files and directories

 fn codeowners_enforcer(         override_builder.add(&format!("!{}", ignore_pattern))?;     } +    // Always ignore .git directory+    override_builder.add("!.git/*")?;

I havent used this tool in a long time so I don't remember. Do you need it to be !.git/* or could it just be !.git/

blimmer

comment created time in 10 days

PullRequestReviewEvent

delete branch jamiebuilds/ecma262

delete branch : object-hasown

delete time in 10 days

CommitCommentEvent

push eventbathos/proposal-string-cooked

Jamie Kyle

commit sha 915523b03d8883e8428b90dd967ef01774fd5af7

Expand overview

view details

push time in 16 days

push eventbathos/proposal-string-cooked

Jamie Kyle

commit sha 21602d6b296eb1fb2c3ac80e1f5d6fc9df663ed3

Update README.md

view details

push time in 16 days

issue commentmdn/content

[JS] Object.hasOwn() shipped

Should this be updated to remove the "experimental technology" warning now that it is stage 4? Or does that refer to browser support specifically?

hamishwillee

comment created time in 17 days

issue commenttc39/proposal-pipeline-operator

Hack-pipe placeholder bikeshedding

To me, the syntax ${} only makes sense for template strings because it has to distinguish itself from an arbitrary set of characters within the string. That's not the situation we're in though, we only have to distinguish it from surrounding syntax which is tightly controlled.

I also don't think many people who aren't language designers would see any sort of relationship between template strings and pipelines.

js-choi

comment created time in 18 days

issue commentbathos/proposal-string-cooked

Function signature bikeshed

Okay, I was under wrong impression then. I'll update the issue

jamiebuilds

comment created time in 18 days

issue commenttc39/proposal-pipeline-operator

Hack-pipe placeholder bikeshedding

I personally find ^^ really nice and would like to push for it.

  • I find it very aesthetically pleasing
  • It creates a nice visual way to remember its purpose for beginners (i.e. "The arrows point 'up' at the previous value" is similar to how many people were taught < and >)
  • It's (more) distinct from existing tokens (at least more than % or ? for example, which are existing tokens, and far more commonly typed tokens)
lookAtHowCuteThisIs
  |> smilingEyes(^^)
  |> joy(^^)
js-choi

comment created time in 18 days