profile
viewpoint
Kyle Simpson getify Getify Solutions Austin, TX http://getify.me I envision and evangelize the future of Open Web technologies, especially JS.

getify/Functional-Light-JS 13407

Pragmatic, balanced FP in JavaScript. @FLJSBook on twitter.

getify/LABjs 2242

Loading And Blocking JavaScript: On-demand parallel loader for JavaScript with execution order dependencies

getify/asynquence 1695

Asynchronous flow control (promises, generators, observables, CSP, etc)

getify/CAF 937

Cancelable Async Flows (CAF)

getify/A-Tale-Of-Three-Lists 636

Comparing various async patterns for a single demo

getify/fasy 461

FP iterators that are both eager and asynchronous

getify/FPO 414

FP library for JavaScript. Supports named-argument style methods.

getify/JSON.minify 356

Simple minifier for JSON to remove comments and whitespace

getify/h5ive-DEPRECATED 333

**DEPRECATED** A collection of thin facade APIs wrapped around HTML5 JavaScript features.

getify/grips 289

Simple-logic templates

issue closedgetify/You-Dont-Know-JS

ES6 & Beyond, Chapter 2: Syntax, using object destructuring to set defaults for a nested object's properties example

Yes, I promise I've read the Contributions Guidelines (please feel free to remove this line).


Please type "I already searched for this issue": I already searched for this issue Edition: (1st or 2nd) 1st Book Title: ES6 & Beyond Chapter: Syntax Section Title: Nested Defaults: Destructured and Restructured Question: The example of setting defaults for a nested object's properties with the help of object destructuring:

({
	log: {
		warn: config.log.warn = defaults.log.warn,
		error: config.log.error = defaults.log.error
	} = {}
} = config);

I couldn't figure out why the trailing part ={} is necessary if at all, because removing it makes no different to the result, and it doesn't make any sense logically. Let's consider a more concise one, e.g. ({log: AA = {}} = config), the way I reason about it is that if there's no log property within config, then variable AA is set to {}; however, you clearly not able to set

{
    warn: ...,
    error: ...
}

to {}, right? Because it's not a valid assignment expression, or is it? Even if it's syntactically valid, we know that config.log is already set to {} with config.log = config.log || {}; in the code listing, it still seems unnecessary.

So, what role exactly the ={} part is playing and why it's necessary? Or is it a mistake? Thanks.

closed time in a day

OahMada

issue commentgetify/You-Dont-Know-JS

ES6 & Beyond, Chapter 2: Syntax, using object destructuring to set defaults for a nested object's properties example

Because it's not a valid assignment expression, or is it? Even if it's syntactically valid

Yes, this would be syntactically valid, but not as useful as one might expect:

({
   log: {
      // ..
   } = { whatever: 42 }
} = config);
OahMada

comment created time in 2 days

issue commentgetify/You-Dont-Know-JS

ES6 & Beyond, Chapter 2: Syntax, using object destructuring to set defaults for a nested object's properties example

...is necessary if at all, because removing it makes no different to the result

Doesn't matter here, but in general all nested destructuring patterns need a default so as to not fail if the nested object/array to be destructured is actually missing. This is a consistency of coding style sort of thing.

OahMada

comment created time in 2 days

pull request commentgetify/You-Dont-Know-JS

docs: Fix simple typo, transpiliation -> transpilation

thanks!

timgates42

comment created time in 3 days

push eventgetify/gum-try-hd

Kyle Simpson

commit sha 0d3ec7d9080f919f15760c2d10733fde9d3dc819

updating README with privacy statement

view details

push time in 5 days

push eventgetify/gum-try-hd

Kyle Simpson

commit sha 8160c39235854b080f2dab1dbafdaf25eab8e0c7

tweaking naming and polishing behavior for store publish

view details

push time in 5 days

push eventgetify/gum-try-hd

Kyle Simpson

commit sha 188ebad83ef942f0111ee557b4f89f98674d4094

improving extension to also apply to, and fix, Google-Meet

view details

push time in 5 days

push eventgetify/gum-try-hd

Kyle Simpson

commit sha 42fec300e38f7a9683ac28d16fb709aa58a1e54d

improving extension to also apply to, and fix, Google-Meet

view details

push time in 5 days

push eventgetify/gum-try-hd

Kyle Simpson

commit sha c1769e9c9af36e82ab99278ad255c39d476ca6ca

adding README and license

view details

push time in 5 days

create barnchgetify/gum-try-hd

branch : master

created branch time in 5 days

created repositorygetify/gum-try-hd

Try to force HD (1280x720) camera resolution for web calls

created time in 5 days

issue commentgetify/LABjs

JsDelivr - I can't see '.js' files

I am not planning to release the old LABjs 2.0.3 onto npm, but the long-running (many years now) effort to rewrite the 3.0 branch, yes, the plan was to put that out on npm (and thus it would be available for jsDelivr and other CDNs).

The 3.0 rewrite was mostly complete, but I stalled out because creating a test environment for script loading is actually really difficult. I was actually building a virtual-DOM sort of thing to fake those behaviors so I could have proper testing, but I never quite finished that effort. Would love help with it. :)

wellington1993

comment created time in 6 days

PR closed getify/You-Dont-Know-JS

Update apB.md

I already searched for this issue

Edition: 2nd

Book Title: Get Started

Chapter: Appendix B: Practice, Practice, Practice!

Section Title: Suggested Solutions

Topic: Suggested solution for "Comparisons" (Pillar 3) practice Suggested solution for "Closure" (Pillar 1) practice

@getify, It is really awesome practice samples! Despite the fact, that I have been writing JS-code for quite a long term, It took me a lot of time to solve them without tips 😅 They make me think for more elegant solutions!

I carefully checked my solution with yours by examining your source code and came across a few code style shortcomings Which, in my opinion, should be fixed to improve code readability

  1. Suggested solution for "Comparisons" (Pillar 3) practice The simpler case typeof meetingStartHour != "string" || (...) should be handled first to avoid over-nesting Makes sense?

  2. Suggested solution for "Closure" (Pillar 1) practice Statement else seems like just redundant as for me

I apologize in advance for my excessive pedantry in the scope of code style

Taking this opportunity to express my deep gratitude to the author for a series of these books!

+44 -46

3 comments

1 changed file

sakastierov

pr closed time in 8 days

PR closed getify/You-Dont-Know-JS

Update Ch8. Custom Change Events section. Fix calc

The original code shows:

obj.a;			// 12
obj.b;			// 30
obj.c;			// 3

But I made the calculation and the result must be:

obj.a;			// 6
obj.b;			// 33
obj.c;			// 3

Because we call to changeObj( 3, 11 ); and:

	obj.a = a * 2;
	obj.b = b * 3;

The final value of the property c is OK because a + b + old value of c is 6 + 33 + 3 that is 42.

Thanks!

Yes, I promise I've read the Contributions Guidelines (please feel free to remove this line).

Specifically quoting these guidelines regarding typos:

Typos?

Please don't worry about minor text typos. These will almost certainly be caught during the editing process.

If you're going to submit a PR for typo fixes, please be measured in doing so by collecting several small changes into a single PR (in separate commits). Or, just don't even worry about them for now, because we'll get to them later. I promise.


Please type "I already searched for this issue":

Edition: (pull requests not accepted for previous editions)

Book Title:

Chapter:

Section Title:

Topic:

+2 -2

1 comment

1 changed file

aaronplanell

pr closed time in 8 days

pull request commentgetify/You-Dont-Know-JS

Update Ch8. Custom Change Events section. Fix calc

This is an old book (not being updated after 5 years) and the API in question also doesn't exist anymore.

aaronplanell

comment created time in 8 days

issue commentgetify/You-Dont-Know-JS

Chapter 2: Functions, Confusing Grammar

OK, it's a minor nit, which I don't typically indulge (especially after a book has been published for almost 9 months). But I can see where there's a little confusion, so I will keep this issue open for if/when I do a future errata update.

brandedcow

comment created time in 8 days

issue commentgetify/You-Dont-Know-JS

Chapter 2: Functions, Confusing Grammar

If it read "Not all languages treat functions as values, but that's essential..." would it read clearer to you?

brandedcow

comment created time in 9 days

startedguybedford/es-module-lexer

started time in 10 days

pull request commentgetify/You-Dont-Know-JS

Update apB.md

Ahhh, so you're talking about early-return pattern in both suggestions. Yeah, so that's my response to both then. Thanks for the feedback.

sakastierov

comment created time in 10 days

pull request commentgetify/You-Dont-Know-JS

Update apB.md

The simpler case typeof meetingStartHour != "string" || (...) should be handled first to avoid over-nesting Makes sense?

That would involve introduction of the "early return" pattern. This is historically a disputed pattern, meaning that some very much believe in it and others very much don't. In this case, for a book aimed at pretty early beginners, I don't want to get into that debate. As you said, it's a stylistic choice, which is why I'm encouraging readers to write whatever feels best to them. These solutions are described as one option, not the canonical best option.

Statement else seems like just redundant as for me

It's not... this range(..) utility does something different if you omit the second parameter (end) vs passing one in. If you omit (the === undefined case), it returns a function to be called later, which basically defers the calculation of the range until that later time. That inner function is where the closure is (remembering start), so it's pretty central to the point of this exercise.

But if you pass in anything (non-undefined, even null), the value passed for end is coerced to a number and the range is calculated and returned right away.

So these two clauses (if and else) are absolutely distinct.

sakastierov

comment created time in 10 days

issue openedgetify/moduloze

check for namespace import used as function call

From: https://github.com/eight04/cjs-es#import-style

Note that if the identifier is used as the callee of a function/new expression, it would be considered as the default member since the namespace is not callable.

Need to check for this corner case and avoid the namespace import in that case.

created time in 12 days

issue closedgetify/Functional-Light-JS

partialRight utility seems to have issue

It is written

The value "z:last" is only applied to the z parameter in the case where f(..) is called with exactly two arguments (matching x and y parameters). In all other cases, the "z:last" will just be the rightmost argument, however many arguments precede it.

but when only one argument is passed as in the second example the "z:last" is not assigned to the right most arguments.

image

closed time in 17 days

Etherum7

startedsindresorhus/is-wsl

started time in 18 days

issue openedsindresorhus/trash

confusion for windows + wsl

I have windows 10 + WSL (v1). I just installed this tool and tried to use it on a file inside WSL... I was expecting it to move the file to my Recycle Bin. It didn't work, but then I realized it put the file (renamed) inside ~/.local/share/Trash/files/ (according to that linux spec I guess).

I now realize this wasn't going to work like I expected since the tool is running in a linux environment (WSL), not actual windows.

I'm not sure if there's any way to get this tool installed out in windows land and still be able to run it from inside WSL to do what I expected, but if that's possible it would be nice to add something about that to the documentation.

Alternately and minimally, it might be a good idea to point in the docs out that installing under WSL in Windows is actually installing in linux, and pointing out where deleted files will go. Could remove some future confusion I had for the last ~20 minutes.

created time in 18 days

issue commentgetify/Functional-Light-JS

partialRight utility seems to have issue

f(1);  // 1 "z:last"

Here "z:last" is the "rightmost argument" (aka "the last argument")... Note that I didn't say "rightmost parameter". In a variadic-functions language, you are free to pass as few or as many arguments as you want no matter how many parameters are declared. This utility (as with pretty much all others) is applying its logic to the arguments, not the parameter; a function can't really pragmatically self-inspect its own definition to apply logic based on declared parameters.

Etherum7

comment created time in 18 days

delete branch getify/cascadiajs-2020

delete branch : patch-1

delete time in 19 days

push eventgetify/cascadiajs-2020

Kyle Simpson

commit sha dab80eb238bf6f4a45a01a9096f64fd6fd8940b9

adding slides and library links

view details

push time in 19 days

issue closedgetify/You-Dont-Know-JS

Scope and Closures: Counting the parameter of Console.log() as a target variable.

Please type "I already searched for this issue": I already searched for this issue

Edition: (1st or 2nd) 2nd

Book Title: Scope & Closures

Chapter: 1

Section Title: What's the Scope?

Question: In the section "Compiler Speak" where you enumerate all the source and target variables, you mention there are 5 target variables, I am wondering why we don't count the first argument of the console.log() function in the last line of the code: console.log(nextStudent); As I understand the function log() takes an obj1 parameter (see MDN documentation), so why don't we count this as a target variable for the same reason we count the studentID parameter as a target variable when getStudentName is invoked?

closed time in 21 days

algotrex

push eventgetify/JSON.minify

Rémi Cohen-Scali

commit sha 6a22661101adaef89f76e888f735d340d84bca42

Perl version for JSON minify (#48) added perl port of library Authored-by: Rémi Cohen-Scali <remi@jayacode.fr>

view details

push time in 21 days

PR merged getify/JSON.minify

Perl version for JSON minify

Hi !

Here is a pull request for the Perl port of JSON minify. Status: Port is complete and all tests pass. The Perl modules is not yet finish but I can go on with it while merging in getify perl branch. Once perl Module will be OK I'll post on CAPN (comprehensive perl archive network) and I'll update README to describe install from sources (repo) and from CPAN archives (distrib).

+946 -23

9 comments

14 changed files

rcoscali

pr closed time in 21 days

pull request commentgetify/JSON.minify

Perl version for JSON minify

I don't know much about Perl, but this looks reasonable to me. Thanks for sticking with this! Merging. :)

rcoscali

comment created time in 21 days

PullRequestReviewEvent

issue commentgetify/You-Dont-Know-JS

Scope and Closures: Counting the parameter of Console.log() as a target variable.

The nextStudent there is an argument, not a parameter. The difference is in what's passed in at the call-site vs what's received in the function signature. An argument is a value or source-reference variable, whereas a parameter is a target-reference. If we were showing the implementation (internally in the engine) of the log(..) function, we'd potentially list out a parameter name for that first parameter, and that would be a target-reference.

algotrex

comment created time in 21 days

PR closed getify/You-Dont-Know-JS

Remove dead link in foreword of Up and Going (1st)

Resolves #1693

Yes, I promise I've read the Contributions Guidelines (please feel free to remove this line).

Specifically quoting these guidelines regarding typos:

Typos?

Please don't worry about minor text typos. These will almost certainly be caught during the editing process.

If you're going to submit a PR for typo fixes, please be measured in doing so by collecting several small changes into a single PR (in separate commits). Or, just don't even worry about them for now, because we'll get to them later. I promise.


Please type "I already searched for this issue":

Edition: (pull requests not accepted for previous editions)

Book Title:

Chapter:

Section Title:

Topic:

+1 -1

1 comment

1 changed file

minimalsm

pr closed time in 21 days

pull request commentgetify/You-Dont-Know-JS

Remove dead link in foreword of Up and Going (1st)

Not accepting changes to the first edition books, per contributions guidelines.

minimalsm

comment created time in 21 days

issue closedgetify/You-Dont-Know-JS

Dead link in Foreword

Please type "I already searched for this issue": I already searched for this issue Edition: (1st or 2nd) 1st Book Title: Up and Going Chapter: Foreword Section Title: Foreward Problem: jennlukas.com seems to be no longer used (checked Jenn's twitter and she doesn't seem to be linking to it herself either)

closed time in 21 days

minimalsm

issue commentgetify/You-Dont-Know-JS

Dead link in Foreword

Not accepting changes to the first edition books, per contributions guidelines.

minimalsm

comment created time in 21 days

issue commenttc39/proposal-cancellation

Automatic cancellation support for Promises

I wish there was a way to determine how many usages of userland "cancellation" semantics on promises are about affirmative cancellation vs just disinterest. My intuition (based mostly just on some anecdotal observations in different code bases) is that the later is greater than the former. But it seems like if there was any way to gather evidence like that, it would help inform the design decisions here. If the majority use-case is actually dis-interest, unthen(..) might be enough.

martinheidegger

comment created time in 23 days

issue commentgetify/moduloze

Explore: should moduloze also support converting "globals-only" (instead of just CJS)

I actually saw this as one of the goals of this feature.

It could be, it's just surprising to me because it's not how UMD's global behavior is typically construed. I'm just very used to being able to load a UMD via a <script> and get basically the same result as if I loaded the source itself. I may be projecting those assumptions onto others, but I was just thinking it would surprise others too.

getify

comment created time in a month

issue commentgetify/moduloze

Explore: should moduloze also support converting "globals-only" (instead of just CJS)

OK, but I thought those you were saying those lines themselves were actually in the UMD boilerplate, seems like I misunderstood.

Let me illustrate the problem this way:

If you take the current snippet, and load that JS file with a <script> tag in a page, you end up with two globals, MyModule and bar. But if you "built" that file with this hypothetical mode of moduloze into UMD format, and loaded that UMD format into the browser with a <script> tag, you have just one global named m or Mz843242394 or whatever.

See this line of the UMD boilerplate:

https://github.com/getify/moduloze/blob/0e20280ae0fadf950a2c1fbe97ee602e9cac19df/src/umd-template.js#L12

The context[name] = .. statement just creates a single global variable of the name name, so since there's no destructuring there, it won't be creating the multiple global declarations (MyModule and bar).

Typically, the "global mode" (via <script> load) of a UMD wrapper is supposed to produce the same sort of effect as if the file wasn't wrapped in the UMD wrapper. If the .js file has a single global declaration (aka "export"), that could still be the case. But in the case where your .js file is declaring multiple globals, the typical UMD boilerplate doesn't have a way to create all those globals from its single "export" assignment.

getify

comment created time in a month

issue commentgetify/moduloze

Explore: should moduloze also support converting "globals-only" (instead of just CJS)

I was assuming that these two snippets from your previous message were implying what the UMD boilerplate itself would be doing, which has destructuring in it:

const { MyModule, bar } = m;
define(['m'], function ({ MyModule, bar }) {
  ...
});

Did I misunderstand your intent there?

getify

comment created time in a month

issue commentgetify/moduloze

Explore: should moduloze also support converting "globals-only" (instead of just CJS)

I think that answers 1 and 2

Eh... not exactly. You've implied a change to the way the UMD boilerplate works, where it's assuming a destructuring of a namespace as opposed to just getting a single value out.

But I can't really think of any way for moduloze to determine, reliably, that you definitely want the destructuring applied for one module's imports, and not for another's (the current status quo). For example:

define(['m','p'],function DEF({ MyModule, bar},Whatever){
   // ..
});

It would have to somehow semantically analyze how a module was being used after import and make a guess. That seems intractably complex given that we're talking about a non-static-module-format in a non-static language.
getify

comment created time in a month

issue commentgetify/moduloze

How is dependency-map used in the ESM and UMD builds?

it wouldn't work right now because of the random names.

It internally works, meaning the modules can all reference each other just fine and all auto-execute. But it doesn't externally work, meaning if another non-moduloze-processed part of your app wants to access these resources, they won't have a name to do so.

But that's not Moduloze's fault, it's the fault that you're talking about a packaging format (UMD/AMD/etc) that requires names but you haven't given it names to use. That's a weakness of the module format, not of the tool.

But I'm wondering if it could, if:

I considered implementing some sort of algorithm to name the resources based on the URL, but ultimately decided that the complexity wouldn't be practical, because even those names would still be problematic in that they wouldn't necessarily always be intuitive/predictable. For example, should those identifiers be camelCased, or CapitalFirst or should they be snake_case, etc? So many nuances and variations, whatever I picked and baked in, would be too difficult for people to rely on in their apps.

It would also mean that the moduloze's naming convention choices implicitly become part of the business logic of any app using it, which means that moduloze is now much more restricted in future changes in that respect (without causing breakage, not to mention the complexity of using modules that were compiled by different versions of moduloze, etc).

if we wanted to integrate this as a feature at jsDelivr, we'd probably want it to be zero-config from the user's perspective.

That makes sense. Unfortunately, there's nothing we can do about the fact that some module systems (like browser globals, AMD, and... ultimately, UMD) require names to load and use modules, not just their URLs. That basically requires some sort of meta-data, either that you (the CDN) are made aware of, or that the author is aware of and uses in their own build.

An author couldn't manually distribute their modules out on jsDelivr (or any CDN) in the UMD/AMD/globals format without having chosen a name for them, or nobody could consume and use them. That's just part of the authoring/distribution process if you plan to support a name-required packaging format.

So I agree, it seems like you can't build them automatically without some source for those names.

Of course, that limitation only applies to UMD. You could still host a service running a tool like moduloze to up-convert from globals/CJS to ESM (minus the index/rollup build), and just not offer the UMD conversion/hosting at all. The benefit of upconverting to ESM should standalone, even if you couldn't take advantage of also upconverting to UMD.


Or, for the UMD support specifically, you could pick some sort of convention, as suggested, like inferring from the filename, or maybe requiring each to be in its own directory and using that name, etc. Then you'd just need to programmatically specify the dependency-map as part of the call to moduloze.

But ultimately, whatever convention you pick there, it'd have to be something that the authors documented for their users, so users knew what identifier names to use in their apps. This seems really brittle for your CDN, with the exact same drawbacks as me baking that stuff into the tool.

The other option is to pick like a convention similar to source maps, where each file to be converted to UMD has to have a "{FILENAME}.umd-map.json" alongside it, providing a name to use. Or whatever other ideas we may bikeshed. That's not exactly "zero configuration", but it doesn't seem all that unreasonable (especially since people and tooling already do sourcemap files similarly).

getify

comment created time in a month

issue commentgetify/moduloze

How is dependency-map used in the ESM and UMD builds?

In UMD builds, the dependency-map is "required" for several reasons, to map resource URLs to their names:

  1. The name of a resource is used by the browser-global aspect of UMD behavior as the registered global identifier (aka, "the export").

  2. The name of a resource is used by the AMD aspect of UMD behavior to register a module definition by its name (aka "the export"), so that this name can later be used by other modules.

  3. The name of that resource is then used by the AMD aspect of UMD behavior in the list of dependencies passed to an AMD module's definition, so that AMD knows which dependency instance(s) to retrieve from its internal definitions and provide to (aka "import for") this module. That same name is also used as the actual parameter identifier in the outer definition function for a module that needs that dependency.

So, if you require(..) some URL that Moduloze doesn't have a name for (no dependency map, or not listed), Moduloze has to generate a unique name (like Mz8382423923) for it, for it to be used in all those various ways.

If the dependency is never referenced elsewhere in the app by some other name, this auto-generated name is probably not a problem. But it absolutely might "break" your app if you're just assuming that "MyCoolModule" will be able to reference it from somewhere else, but you didn't tell Moduloze that name.

That's the main purpose of the dependency-map.

Secondarily, ESM uses the dependency-map if you're also building the "index" / "rollup" ESM module (the one that imports and re-exports all your modules as a single module). It needs names to use in all its re-exports. Of course, if it used auto-generated names for those, none of your code would know (or be able to predict) those bindings, so it'd be unuseful.


BTW, I definitely think something like this discussion should make its way into the "Conversion Guide" docs. That's an open TODO. :)

getify

comment created time in a month

issue openedgetify/moduloze

How is dependency-map used in the ESM and UMD builds?

[Editor: this question was moved here from another thread]

@MartinKolarik:

I briefly checked how moduloze currently works with other formats and I noticed there's a required config option dep-map. I guess it's needed to map require() to UMD globals but I see it's somehow used in ESM processing as well. With an empty map, both ESM and UMD outputs look like I'd expect though. Can you explain briefly why the map is needed to make sure I understand the current approach for UMD/ESM?

created time in a month

issue commentgetify/moduloze

Explore: should moduloze also support converting "globals-only" (instead of just CJS)

Shouldn't bar be exported as well since it's in the global scope? Or do you expect the user to specify which (only one) global is exported?

Yep, it probably should be exported as well. Just overlooked it. Though, that does bring up pesky questions...

  1. basically, all global declarations in such a file could be assumed to be needed, so they can all be named exports easily for both ESM and the CJS side of UMD. But what about multiple named exports for the browser globals and AMD sides of UMD? it doesn't really support that.

  2. if there's only one global, should it also be a default export (ESM)? should it be the "main export" of the UMD form? would this be INSTEAD OF, or IN ADDITION TO, the named export?

  3. but if there's multiple globals, do we do no default exports, or just pick the first one?

getify

comment created time in a month

issue openedgetify/moduloze

Explore: should moduloze also support converting "globals-only" (instead of just CJS)

https://twitter.com/LeaVerou/status/1285320583408955401?s=20

created time in a month

pull request commentgetify/You-Dont-Know-JS

typo fix: indisputedly -> indisputably

Thanks!

johnnycopes

comment created time in a month

issue commentgetify/You-Dont-Know-JS

Scopes & Closures Ch. 6 - Switch Statement Scoping

The case items themselves should be seen as they are all in one scope.

This isn't entirely true, since if you put { .. } around the statements of a single case clause, that is a nested block-scope.

ericmathison

comment created time in a month

issue commentgetify/You-Dont-Know-JS

Scopes & Closures Ch. 6 - Switch Statement Scoping

@KarenEfereyan This isn't really a "project" per se. It's a series of books I wrote (and am writing). Contributors are primarily those who find typos that my copyeditor may have missed, or occasionally find technical mistakes (such as this thread).

ericmathison

comment created time in a month

pull request commentgetify/You-Dont-Know-JS

eek -> eke

Good catch, thanks.

philip-healy

comment created time in a month

issue commentSublimeLinter/SublimeLinter

Cannot get SublimeLinter on windows working

Yeah, they're definitely sending back a fully qualified path:

[{
    "filePath": "/mnt/c/Users/whatever/Desktop/test.js",
    "messages": [{
        "ruleId": "no-floating-decimal",
        "severity": 2,
        "message": "A trailing decimal point can be confused with a dot.",
        "line": 1,
        "column": 9,
        "nodeType": "Literal",
        "messageId": "trailing",
        "endLine": 1,
        "endColumn": 11,
        "fix": {
            "range": [10, 10],
            "text": "0"
        }
    }],
    "errorCount": 1,
    "warningCount": 0,
    "fixableErrorCount": 1,
    "fixableWarningCount": 0,
    "source": "var x = 1.;\n",
    "usedDeprecatedRules": [{
        "ruleId": "handle-callback-err",
        "replacedBy": []
    }, {
        "ruleId": "id-blacklist",
        "replacedBy": ["id-denylist"]
    }, {
        "ruleId": "no-buffer-constructor",
        "replacedBy": []
    }, {
        "ruleId": "no-catch-shadow",
        "replacedBy": ["no-shadow"]
    }, {
        "ruleId": "no-native-reassign",
        "replacedBy": ["no-global-assign"]
    }, {
        "ruleId": "no-negated-in-lhs",
        "replacedBy": ["no-unsafe-negation"]
    }, {
        "ruleId": "no-new-require",
        "replacedBy": []
    }, {
        "ruleId": "no-path-concat",
        "replacedBy": []
    }, {
        "ruleId": "no-restricted-modules",
        "replacedBy": []
    }, {
        "ruleId": "valid-jsdoc",
        "replacedBy": []
    }]
}]

So, if the plugin sends in just a filename, could the plugin then strip off all but the response filename, and then fully qualify it based on the current working directory?

getify

comment created time in a month

issue commentSublimeLinter/SublimeLinter

Cannot get SublimeLinter on windows working

BTW, if I try to specify a custom location for the config file via the args array, I get an interesting error that seems to indicate that SL is trying to parse out and handle configs manually?

args: ["-c ~/some/other/config.json"]

The error is:

Value for 'config' of type 'path::String' required.

If I instead do:

args: ["-c", "~/some/other/config.json"]

I get the path munging problem, where that the error reported says the config can't be found and what it reports is a really messed up path string.

getify

comment created time in a month

issue commentSublimeLinter/SublimeLinter

Cannot get SublimeLinter on windows working

I added those to my config, and this is what the error says now:

SublimeLinter: WARNING: eslint reported errors coming from '\mnt\c\Users\whatever\Desktop\test.js'. However, reading that file raised:
  [WinError 3] The system cannot find the path specified: '\\mnt\\c\\Users\\whatever\\Desktop\\test.js'.

So, the path munging problem seems to have been fixed, or at least significantly improved? But it's still not working.

Notable that, from the perspective of eslint inside WSL, the path \mnt\c\Users\whatever\Desktop\test.js is completely valid. But that path makes no sense outside of WSL, so I would guess this error is that SL doesn't know what to do with that path?

getify

comment created time in a month

issue commentSublimeLinter/SublimeLinter

Cannot get SublimeLinter on windows working

If we just send the filename (not the absolute path), no linter will probably make sense of it. They will assume this is relative to the working dir.

Understood, that makes sense. Would it be impractical to change the CWD to where the file being linted is (usually, just the current open file, right) before sending it to eslint, and then perhaps revert the CWD back after getting the results back?

getify

comment created time in a month

issue commentSublimeLinter/SublimeLinter

Cannot get SublimeLinter on windows working

Also... I just tried this from the CMD windows command line:

C:\Users\whatever\Desktop>wsl eslint -c ~/.eslintrc.json test.js

/mnt/c/Users/whatever/Desktop/test.js
  1:9  error  A trailing decimal point can be confused with a dot  no-floating-decimal

✖ 1 problem (1 error, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

IOW, if I provide a single filename to eslint, it works properly. It's only if I tried to provide a fully qualified (or relative) path that I see the path issues cropping in.

Would it be feasible for SL (and the eslint plugin) to only provide just the filename (in the cross-wsl boundary call) and not a full path?

getify

comment created time in a month

issue commentSublimeLinter/SublimeLinter

Cannot get SublimeLinter on windows working

So, just to clarify, this is a problem without a workaround, as far as the current situation is concerned?

I don't know any python, but I wouldn't mind trying my hand at a PR, if you had any suggestions about approximately where such path-translation logic might need to go?

getify

comment created time in a month

issue commentSublimeLinter/SublimeLinter

Cannot get SublimeLinter on windows working

OK, so I'm now getting errors like this:

SublimeLinter: WARNING: eslint reported errors coming from '\mnt\c\Users\whatever\Desktop\C:UserswhateverDesktoptest.js'. However, reading that file raised:
  [WinError 3] The system cannot find the path specified: '\\mnt\\c\\Users\\whatever\\Desktop\\C:UserswhateverDesktoptest.js'.

So I take it that's what you meant about the path problem?

getify

comment created time in a month

issue commentSublimeLinter/SublimeLinter

Cannot get SublimeLinter on windows working

Oh, also, there's a command called wslpath you can run to translate paths. It's (perplexingly) inside of WSL, but you can access it from the outside like this:

wsl wslpath
Usage:
    -a    force result to absolute path format
    -u    translate from a Windows path to a WSL path (default)
    -w    translate from a WSL path to a Windows path
    -m    translate from a WSL path to a Windows path, with '/' instead of '\'
getify

comment created time in a month

issue commentSublimeLinter/SublimeLinter

Cannot get SublimeLinter on windows working

Just curious, why does the linter need to send it a filename/filepath? Does it not feed the contents of the open file directly to eslint? How does it lint while typing if you haven't saved a file yet?

getify

comment created time in a month

issue commentSublimeLinter/SublimeLinter

Cannot get SublimeLinter on windows working

BTW, here's my full SL config:

{
	"delay": 5,
	"gutter_theme": "Default",
	"highlights.demote_while_editing": "all",
	"highlights.time_to_idle": 5,
	"lint_mode": "load_save",
	"linters": {
		"eslint": {
			"executable": "\\\\wsl$\\Debian\\usr\\local\\bin\\eslint",
			"disable": false,
			"args": ["-c ~/.eslint.json"],
			"excludes": [],
			"styles": [
				{
					"priority": 1,
					"mark_style": "none"
				}
			]
		}
	},
	"show_marks_in_minimap": false
}
getify

comment created time in a month

issue openedSublimeLinter/SublimeLinter

Cannot get SublimeLinter on windows working

I have installed SublimeLinter plugin for ST3 install in windows 10, as well as the sublimelinter-eslint plugin. However, I'm having trouble getting it to start correctly.

I have eslint installed inside my WSL instance, so from windows, to execute binaries inside of WSL, the command is like wsl eslint", where that wsl program (provided by windows) does the bridging. If you run that command from a normal CMD prompt, it works fine.

However, when I configured SublimeLinter-eslint like this:

"executable": "wsl eslint"

I get this error in the ST3 console:

You set 'executable' to 'wsl eslint'. However, 'which wsl eslint' returned nothing. Try setting an absolute path to the binary.

I tried changing the path to:

"executable": "\\\\wsl$\\Debian\\usr\\local\\bin\\eslint"

From inside the WSL terminal, you can run /usr/local/bin/eslint and it definitely runs. But unfortunately, when I set that absolute path, I get a different error in the ST3 console:

SublimeLinter: WARNING: eslint cannot locate 'eslint'

So I'm stuck, not sure what to do?

created time in a month

push eventgetify/fasy

Chidi Williams

commit sha 9120a62af938bb364770020c933a855c7a049d25

Updating generator-runner link in README

view details

Kyle Simpson

commit sha eead510bc3e831d3699bcd492cdac85b21f19a85

Merge pull request #12 from chidiwilliams/patch-1 Updating generator-runner link in README

view details

push time in a month

PR merged getify/fasy

Updating generator-runner link in README
+1 -1

1 comment

1 changed file

chidiwilliams

pr closed time in a month

pull request commentgetify/fasy

Updating generator-runner link in README

Good catch, thanks!

chidiwilliams

comment created time in a month

created taggetify/monio

tag0.3.0

Async-capable IO Monad (including "do" style) for JS, with several companion monads thrown in

created time in a month

push eventgetify/monio

Kyle Simpson

commit sha a04d5d9e9a75aa8095842de52ddac74e46a1d5ac

fixing bug with Maybe(..) regarding nested Maybe values and '_inspect()' output

view details

push time in a month

issue commentgetify/You-Dont-Know-JS

Scope & Closures, Ch 3- Different behavior observed than stated "can't reassign the BLUE(2) special parameter"

That's not re-assigning the BLUE special... that's mutating the contents inside the object that the BLUE special points to, by virtue of a copied reference to that object. Those are entirely different things. There is absolutely no way to access the shadowed BLUE special as a lexical identifier, meaning there's no way to re-assign it.

vikrantuk

comment created time in a month

delete branch getify/postmeritocracy

delete branch : patch-1

delete time in a month

push eventgetify/postmeritocracy

Kyle Simpson

commit sha 935c5ec602cbe7d68a76bf4faa5fe9e1c6870961

adding myself to the list!

view details

push time in a month

PR closed getify/You-Dont-Know-JS

make books interactive

Yes, I promise I've read the Contributions Guidelines (please feel free to remove this line).

Specifically quoting these guidelines regarding typos:

Typos?

Please don't worry about minor text typos. These will almost certainly be caught during the editing process.

If you're going to submit a PR for typo fixes, please be measured in doing so by collecting several small changes into a single PR (in separate commits). Or, just don't even worry about them for now, because we'll get to them later. I promise.


Please type "I already searched for this issue": I already searched for this issue Edition: (pull requests not accepted for previous editions) any Book Title: any & all Chapter: any & all Section Title: any & all Topic: any & all


It just allows people to use gitpod on the repo with preinstalled extensions that you as an author to give guided codetours, pair programming with codetogether, etc. The hope is to make your content more interactive. I hope you try it out with an open mind 😄

+13 -0

3 comments

2 changed files

HansUXdev

pr closed time in 2 months

pull request commentgetify/You-Dont-Know-JS

make books interactive

Appreciate the screencapture illustrating what you're referring to. I don't think that's a broadly applicable enough experience to roll into the main repo, but that's a perfect example of something you can do when you fork the repo and want to customize your experience.

HansUXdev

comment created time in 2 months

issue commentjavascript-tutorial/en.javascript.info

DataTypes in JavaScript

https://github.com/mdn/mdn/issues/98#issuecomment-673513692

GangulyRit

comment created time in 2 months

issue commentmdn/mdn

Issue in data Types

If we're talking about the spec, function isn't its own specific type (despite the typeof behavior), it's a sub-type of object.

If we're talking about developer ergonomics, function is definitely its own type since it has very specific behavior that other object values don't have.

So... it depends.

For the record, the same can be asked of arrays... the spec says they're a subset of object, but they definitely have special behavior we rely on that's different from normal objects.

GangulyRit

comment created time in 2 months

pull request commentgetify/You-Dont-Know-JS

make books interactive

I hope you try it out with an open mind

You didn't really provide any context, so how could I have an open mind? I've never heard of gitpod, so I haven't the faintest clue what you're asking me to enable. And the diff isn't clear either. Adding a random .yml file without any context is not on my priority list.

I googled gitpod, seems like it lets you make docker images from github repos. But still, that doesn't explain at all how you're proposing that this would make this repo "more interactive"? Moreover, being "interactive" is not particularly a goal of this repo.

I'm confused as to what I'm supposed to think of this contribution?

HansUXdev

comment created time in 2 months

issue commenttc39/proposal-record-tuple

Collect developer feedback about the ergonomics of `#{ }`/`#[ ]`

Polling your own followers means

Assuming that (most/all) of my followers agree with me, or are even biased to tend to agree with me general, is a flawed premise. To my surprise, I quite often have quite vocal opposition to opinions I share, even from my most ardent of followers. A lot of people follow me if for no other reason than to share differing/opposing opinions with me.

Morever, most polls that I post "only to my followers" only get a few hundred responses at most. In this case, I knew that for the results to be more useful, it needed to expand to a broader audience. I ran it for 3 days instead of a few hours like I normally do, and I explicitly asked for additional responses in several different channels (linked-in, some different slacks I'm in, etc). I also asked for RTs (56 suggests it was spread around somewhat beyond my circle), even those in other language communities that definitely aren't my followers or even know who I am.

Of course, I don't know who responded. But to have 1,240 responses to one of my polls is 3-5x what I would normally expect, so I think it highly unlikely that the majority of these responses were from my followers wishing to just "yes vote" affirm whatever I say.

...skewed...what could be seen as your expectations, even if just from context cues.

I also tried to make the wording as neutral as I could manage so as to not suggest my opinion on the topic. I haven't talked about this issue before publicly on twitter, so my followers wouldn't have any way of knowing how I feel, unless they had also found and read this thread.

Insofar as it's possible to pull any sort of useful evidence from online polls or surveys, I think I did a reasonable job of trying to get fair feedback. I wouldn't have posted results here otherwise.

littledan

comment created time in 2 months

pull request commentgetify/You-Dont-Know-JS

Simple typo

Thank you, I will pick this up in the next round of errata updates.

mammadjafar

comment created time in 2 months

issue commenttc39/proposal-record-tuple

Collect developer feedback about the ergonomics of `#{ }`/`#[ ]`

I guess let this stand as a monument to motivated reasoning

Agreed, I think we're making progress in this thread (even if we're not agreeing) in that we're finding ways to articulate valid (if opposite) viewpoints more clearly.

But you only ever see something for the first time once

This is true.

But what's also true is that programmers are not machines, so they don't always "see an unfamiliar thing once, look up the answer, get a perfect understanding of it, then move on and never forget or have further confusion". The reality, IME, is often much messier.

This is especially true since we're talking about syntax, and the # character is not something that will be easily google'able to find this exact new usage. I can't tell you how many times I've had people complain about not knowing what to call some operator or syntax, like the ?. for example, in their searches. Finding relevant material on these things is very challenging when you don't even know what to call it. And even if they get lucky and find something relevant, the materials are often imperfect (or flat out wrong).

So it turns out that the process of going from "I've never seen this before" to "I know and recognize that, and have a solid understanding of what it is", is a lot more complex than flipping a bit. That's why those first impressions/intuitions factor heavily in the early learning of a feature -- they guide initial mental models, assumptions, and even the words we use to google or stackoverflow to ask for help.

littledan

comment created time in 2 months

pull request commentgetify/You-Dont-Know-JS

Fix various errata in Async & Performance Ch. 4: Generators

Here's an illustration of how the book's version of thunkify(..) utility is "broken":

function thunkify(fn) {
	return function() {
		var args = [].slice.call( arguments );
		return function(cb) {
			args.push( cb );
			return fn.apply( null, args );
		};
	};
}

var f = thunkify((x,y,cb) => cb(x + y));

var seven = f(3,4);

seven(sum => console.log(`Seven: ${sum}`));    // Seven: 7
seven(sum => console.log(`Another Seven: ${sum}`));    // Seven: 7     <---- Oops
seven();   // Seven: 7    <------- WHAT!?

We would have expected the next-to-last line to print Another Seven: 7, but it didn't. The shared closure over args modified the list in the first seven(..) call to add the first version of the callback. From then on, all subsequent calls to seven(..) don't pay any attention to what callback you pass in.

Compare to the corrected thunkify(..):

function thunkify(fn) {
	return function() {
		var args = arguments;
		return function(cb) {
			var thunk_args = [].slice.call( args );
			thunk_args.push( cb );
			return fn.apply( null, thunk_args );
		};
	};
}

var f = thunkify((x,y,cb) => cb(x + y));

var seven = f(3,4);

seven(sum => console.log(`Seven: ${sum}`));     // Seven: 7
seven(sum => console.log(`Another Seven: ${sum}`));     // Another Seven: 7

So, yes, the book's version is broken and that's regrettable. But it was enough of a substantive change (and would have needed corrective text to explain), and the book had already been out for quite awhile at that point... so I opted not to modify the book. At some point, a second edition will be written, and this issue will be addressed then.

airandfingers

comment created time in 2 months

issue commenttc39/proposal-record-tuple

Collect developer feedback about the ergonomics of `#{ }`/`#[ ]`

I would like to enter this tiny piece of highly anecdotal evidence into the discussion record on the recent debate of if #foo = #{ a: 1 } "...is clear about what’s what"?

results for poll (1,240 votes): 54.4% chose

(https://twitter.com/getify/status/1291707811009830913)

Don't read too much into my intent of asking the poll or sharing it here. Twitter polls are clearly neither scientific nor definitive, and no poll wording is ever perfect. And it's also asking a very narrow question, about first impressions of a syntax, at a glance.

But my claim earlier was that if I glanced at a line of code that used the # on both sides of the =, my first instinct would be to think they were in some way related. I was extrapolating that, from my experience with lots of new learners of JS, it might be the case that others would infer a relation/connection. I was imagining initial incorrect assumptions like "private fields are only supposed to have tuples/records assigned, not objects/arrays" or "you're only supposed to assign tuples/records to private fields, not normal properties".

I combat a lot of assumption/inference based incorrect information out in the wild as blog posts about JS topics spread around the community. It's why I'm cautious of designing things that could contribute to that trend.

54.4% to 45.6% is not overwhelming proof by any means, but I do think it's somewhat suggestive that it's perhaps not quite as "clear", "obvious", and "unambiguous" as is claimed. 1,240 votes might not be enough for a truly representative sample, but it's certainly more than the few of us who are discussing the topic here.

I'm not saying this is definitive strong evidence against the syntax. But I do think first impressions, intuitions, and inferences about syntax design should at least be considered. At a minimum, those concerns should influence how the eventual feature is named, discussed in the spec and associated blog posts and early code examples, etc.

littledan

comment created time in 2 months

issue commenttc39/proposal-record-tuple

Collect developer feedback about the ergonomics of `#{ }`/`#[ ]`

are significantly different.

I don't consider glancing at a simple assignment statement and seeing # on the left and on the right, in the first position of both sides, no doubt, "significantly" different. That's not an assertion of them not being technically different, it's an assertion of them not looking a lot different, especially at a glance.

I don't care to get into a debate about what's allowed to be subjective or not.

littledan

comment created time in 2 months

issue commenttc39/proposal-record-tuple

Collect developer feedback about the ergonomics of `#{ }`/`#[ ]`

#foo = #{ a: 1 } is clear about what’s what.

Not to my eyes. To me that's the opposite of "clear". I look at that and have to double take to confirm in my mind that the two #s aren't related. My only point is that it's subjective, yet repeated assertions in this thread like "obvious and unambiguous" keep making the opinion sound like it's objective.

littledan

comment created time in 2 months

issue closedgetify/You-Dont-Know-JS

Get Started: character encoding bugs in exports

Some character encoding issues in the "Get Started" ebook PDF (leanpub) and print (from Amazon):

• in the ebook version, in the Foreword, page 9 (page “i" of the text), second paragraph, third line: — instead of “—" • in the ebook version, in Appendix A, page 120 (page “102” of the text), next to last line of the page: — instead of “—" • in the ebook version, in Appendix B, page 132 (page “114” of the text), third to last line of the page: — instead of “—"

closed time in 2 months

getify

issue commentgetify/You-Dont-Know-JS

Get Started: character encoding bugs in exports

Fixed this with settings at leanpub.

getify

comment created time in 2 months

push eventgetify/You-Dont-Know-JS

Henré Botha

commit sha 4fdf7e0225b8c405f70fbb57594dd305646216c7

Fix grammar

view details

Kyle Simpson

commit sha 74a7f6ab97198da2d20be135c63bedf2c853bfb0

Merge pull request #1665 from henrebotha/patch-1 Fix grammar

view details

push time in 2 months

PR merged getify/You-Dont-Know-JS

Fix grammar

I already searched for this issue :upside_down_face:

+3 -3

5 comments

1 changed file

henrebotha

pr closed time in 2 months

push eventgetify/You-Dont-Know-JS

Kyle Simpson

commit sha 3fad40656b24578071d29af8d23fdf651316568a

get started, apB: fixing mistake in solution code, closes #1678

view details

push time in 2 months

issue closedgetify/You-Dont-Know-JS

get started: appendix B, prototype solution

Replace reel.display.call(slot) with simpler (and more illustrative of the point!) slot.display().

closed time in 2 months

getify

issue openedgetify/You-Dont-Know-JS

Get Started: character encoding bugs in exports

Some character encoding issues in the "Get Started" ebook PDF (leanpub) and print (from Amazon):

• in the ebook version, in the Foreword, page 9 (page “i" of the text), second paragraph, third line: — instead of “—" • in the ebook version, in Appendix A, page 120 (page “102” of the text), next to last line of the page: — instead of “—" • in the ebook version, in Appendix B, page 132 (page “114” of the text), third to last line of the page: — instead of “—"

created time in 2 months

push eventgetify/eslint-plugin-proper-arrows

Denis Sikuler

commit sha fec158cb0a006ad50270e7c31ebd67b3d2dd8c14

fixing several typos in README

view details

Kyle Simpson

commit sha e5e1712be5a44aa7d0929d2e0e01ee8ac68e518f

Merge pull request #33 from gamtiq/patch-1 fixing several typos in README

view details

push time in 2 months

pull request commentgetify/eslint-plugin-proper-arrows

fixing several typos in README

Thank you!

gamtiq

comment created time in 2 months

issue commentgetify/moduloze

User feedback suggestions

OK, I just published v0.4.2 which fixes the bugs with a missing .mzrc or dependency-map.

Perhaps you could re-try it now with the update?

horacioh

comment created time in 2 months

created taggetify/moduloze

tag0.4.2

Convert CommonJS (CJS) modules to UMD and ESM formats

created time in 2 months

push eventgetify/moduloze

Kyle Simpson

commit sha 0e20280ae0fadf950a2c1fbe97ee602e9cac19df

fixing bugs with missing config and/or dep-map, closes #5

view details

push time in 2 months

issue closedgetify/moduloze

moduloze should operate without any .mzrc present

Currently, a missing ./.mzrc config file throws an error. It should just silently move on with defaults.

closed time in 2 months

getify
more