Darien Maillet Valentine

The option to remove the directives exists for authors who serve the code — even if present in third party libraries, they can stripped if desired. But it’s rather important...

You can’t, in that example (platform-defined built-in modules). They’re part of the browser, they just might be implemented in JS even if not falling back on a ‘polyfill’ (the term...

Yeah, it shouldn’t be. I’m surprised Uglify keeps unknown ones, though, since Uglify does a number of unsafe transformations by default. Terser does strip them: 

Aside: This thread has been instructive — the responses have helped me understand the API and the motivations behind its design decisions better than I’d previously been able to work...

This will fix #2669 (I think. Does this fix it for only static blocks, or both static blocks and static initializer expressions?)

@Jabher It’s already possible to do this today generically (i.e. without engine-specific tools like prepareStackTrace). You use generators and `yield *` expressions to “unwind” the call stack at every juncture...

@Jabher I tend to agree that a directive isn’t the best way to solve this (at least outside of a niche within an already-niche set of use cases). > you...

@Jabher when you say “browser plugins,” are you referring to something other than extensions like in Chrome and Firefox? Their “content script” injection model uses “isolated worlds” (same-agent realms that...

> The source code is still visible from the original file @taylorhakes that’s not a language-level runtime introspection capability. it’s irrelevant to the goals of this proposal.

Perhaps the word “reliance” has thrown people off because some folks read this as “author reliance”? The proposal concerns only runtime information channels within ECMAScript code, not information available to...