Re: [PROPOSAL] Provide a way to enforce integrity check on module imports

The problem with inlining the integrity into every import site is that this is naturally incompatible with import maps. On Sat, 1 Aug 2020 at 08:57, Jordan Harband wrote: > That seems like something that could possibly be achieved via > https://github.com/tc39/proposal-import-assertions > > On

Re: Are ES Modules garbage collected? If so, do they re-execute on next import?

ever. > > > > Accordingly, I think Allen, if it was Allen, made the right call for ESM. > > > > On Thu, Jul 16, 2020 at 3:23 PM Guy Bedford > wrote: > >> > >> Node.js in the CommonJS loader and dynamic loaders like SystemJS have > supported module

Re: Are ES Modules garbage collected? If so, do they re-execute on next import?

Node.js in the CommonJS loader and dynamic loaders like SystemJS have supported module unloading for many years by permitting eviction from the loader registry. Evicting the full parent tree was the traditional reloading workflow in SystemJS, but live binding pushes are also permitted in SystemJS

Re: Double wildcard "re-exports"... off-limits forever?

Did you mean to have both examples use ‘export const a = 1’? This ambiguous export case is supposed to be an explicit error from the spec. If the export is being stripped and not throwing an error sounds like a possible browser bug. On Fri, Feb 14, 2020 at 09:09 Jordan Harband wrote: >

Re: Proposal: `await.all {...}` for parallelism

Typically I find I want to loop over an iterator of items and apply a function body of work on them in parallel. So it would be nice to support full blocks of statements that can do this work in parallel, instead of relying on just expressions or functions to achieve this. Extending for loops to

Re: Proposal: export ** from './FooBar'

export ** has been suggested before, and it does seem like it would be a useful proposal to me. On Sun, Mar 3, 2019 at 8:17 AM Jordan Harband wrote: > https://github.com/tc39/ecma262/pull/1174 adds `export * as someName from > 'path'`; https://github.com/tc39/proposal-export-default-from is the

Re: [strawman] Symbol.thenable proposal

bility to make ModuleRecords (for modules that > export a > > `then` function) not be considered thenable. > > > > On Fri, Apr 13, 2018 at 8:02 AM, Guy Bedford <guybedf...@gmail.com> > wrote: > >> > >> It's worth noting that the driving use case here is comi

Re: [strawman] Symbol.thenable proposal

It's worth noting that the driving use case here is coming from NodeJS development hitting issues where the guaranteed result for dynamic import resolution can't be assumed to be a module namespace, although please correct me if I'm wrong here Gus. Alternatively could this mitigation be handled

Re: A WeakMap where values (not keys) are weak references?

I hope it wouldn't be too redundant to ask here again if there's been any movement on the WeakRefs proposal? WebAssembly at 1.0 does seem to bring new needs for this. On Tue, 21 Mar 2017 at 18:04, Mark S. Miller wrote: > What you are asking for is sometimes called a

Re: System.import()?

It's great to see more interest in dynamic loading here. The contextual loader may be worth considering as a focus here - this is the special contextual loading syntax to effectively provide a scoped System.import call whose referrer is locked to the current module (`import module from this` as

HostGetSource and HostNormalizeModuleName

Do the HostGetSource and HostNormalizeModuleName functions allow for asynchronous completion, or are they expected to be synchronous? Specifically I'd be interested to hear if the browser loader would run its own dependency tree handling or if it should rely on these hooks implicitly managing the

Re: Importing global into modules.

The global could potentially be available via the this module meta syntax: import { global } from this module; On 8 October 2014 16:34, Brian Di Palma off...@gmail.com wrote: On Wed, Oct 8, 2014 at 3:21 PM, caridy car...@gmail.com wrote: var myGlobalFunction =

Re: dynamic synchronous import

On 28 September 2014 07:01, John Lenz concavel...@gmail.com wrote: I would like to see some way to preload everything, and be able to retrieve them synchronously, something like: System.loader.addNoAsync('...'); // throw if all imports aren't available already So that the script could

Detecting if an object is a Module

We had a discussion back in Feb about a potential Module.isModule function. Since then, Module has been moved to being created through Reflect.Loader.prototype.newModule. So it sounds like a Reflect.isModule or Reflect.Loader.prototype.isModule may be the way to go. Which of these would be

Re: import script -- .esm

The question of whether a file is a module or script is the same problem as to whether a module is ES6 or AMD or CommonJS. Moving it to the extension makes as much sense as having every CommonJS module written as `script.cjs`. We know that we need outside metadata to work out how to interpret

Re: import script -- .esm

On 10 September 2014 19:23, Kevin Smith zenpars...@gmail.com wrote: In NodeJS, this can be through `package.json` properties which inform what module format the package is. Right - although having a runtime system looking at json config files is a terrible idea. : ) In es6now, I'm

Re: import script -- .esm

On 10 September 2014 19:18, John Barton johnjbar...@google.com wrote: On Wed, Sep 10, 2014 at 10:07 AM, Guy Bedford guybedf...@gmail.com wrote: The question of whether a file is a module or script is the same problem as to whether a module is ES6 or AMD or CommonJS. Moving

Re: import script -- .esm

this mechanism doesn't exist by default - but you can create it easily with the loader hooks in just a few lines. On 10 September 2014 20:14, John Barton johnjbar...@google.com wrote: On Wed, Sep 10, 2014 at 11:02 AM, Guy Bedford guybedf...@gmail.com wrote: On 10 September 2014 19:18, John

Re: import script -- .esm

you load CommonJS through the loader, your problem of module or global becomes one of CommonJS or ES6 module in the scenarios you are looking at. On 10 September 2014 23:31, John Barton johnjbar...@google.com wrote: On Wed, Sep 10, 2014 at 11:28 AM, Guy Bedford guybedf...@gmail.com wrote

Re: Delaying execution of modules in the loader

The loader is designed to enable deferred execution, but there isn't an easy hook to allow this that I know of. System.define is the only load function that does not ensure execution. The others (System.import, System.load, System.module), run an EnsureEvaluated call to run the scripts. It could

Re: Loader vs ES6 Classes

I suppose the point is whether System can be subclassed itself, since that is usually the starting point for a new loader as it is common to share the base environment normalization, locate and fetch functions. Currently, if System is set via the options hooks this isn't possible. Note also that

Re: Re: Quantifying Default Exports

This is why I have previously posted asking for a function to determine if a given object is a module object. Given such a function, *Reflect.isModule* say, we can convert our code to AMD or CommonJS like the following: import p from 'module'; Converts to CommonJS: var module =

Re: Re: Quantifying Default Exports

In Brian's case we actually need default exports. This is because the dynamic loader can't pick up the code he has written right now in ES6. This is how he is loading a NodeJS module in ES6: module minimist from 'minimist'; In ES6 this means give me the Module object with getters to the

Re: Re: Quantifying Default Exports

have for AMD compilations at the moment, which seems to have been working well. On 21 July 2014 10:17, John Barton johnjbar...@google.com wrote: On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford guybedf...@gmail.com wrote: In Brian's case we actually need default exports. This is because

System as a SystemLoader class

Currently if I want to subclass the System loader I need to do something like - var newLoader = new Loader(System); newLoader.fetch = function() { // ... } Effectively we're monkey-patching, which isn't pretty. It would be nice to be able to do: class newLoader extends System.constructor {

Re: System as a SystemLoader class

to say here is This platform's built in loader hooks, not The loader hooks some random other package wrote onto System. jjb On Mon, Jul 14, 2014 at 10:39 AM, Guy Bedford guybedf...@gmail.com wrote: Currently if I want to subclass the System loader I need to do something like - var

Re: Loader Hooks

, 2014 at 10:33 AM, caridy car...@gmail.com wrote: Calvin, I don't fully understand what you mean by manipulate the exports and imports. I assume you're talking about native modules since you already have full control over the dynamic modules workflow. Maybe Guy Bedford can provide more details

debugging modules

If I load a module, where one of the dependencies of that module throws in its immediate execution, the module I loaded will return successfully, while the error will be thrown in the environment. There is no way to currently see the tree that caused that module to be loaded in the first place.

Re: debugging modules

...@mozilla.org on behalf of Guy Bedford guybedf...@gmail.com *Sent:* Tuesday, June 24, 2014 14:11 *To:* es-discuss *Subject:* debugging modules If I load a module, where one of the dependencies of that module throws in its immediate execution, the module I loaded will return successfully, while

Understanding module bindings

I was just looking to clarify how module bindings behave. What happens in the following example: export var template = '...template string...'; export var counter = 0; export var obj = {}; template += 'post-script'; counter++; obj = { new: 'obj' }; Do these throw an error? Does the exported

Re: ES6 modules (sorry...)

The latency problem caused by tree depth can also be solved with a Link prefetch header (when Chrome re-enables this) from a server trace or a simple loader extension that contains a traced dependency cache. Injecting a trace tree is a much simpler and better alternative to bundling as we get the

Re: Rationale for dropping ModuleImport syntax?

On 11 June 2014 14:01, Matthew Robb matthewwr...@gmail.com wrote: On Wed, Jun 11, 2014 at 1:53 PM, John Barton johnjbar...@google.com wrote: The Traceur project would be interested in your issues and in a discussion on how to improve. Improvements are easy to try. jjb No matter what

Re: Integrating the Webs' dependency systems

Here is a working example of dependency tree caching with an ES6 loader extension - https://github.com/systemjs/systemjs/blob/master/lib/extension-depCache.js This allows dependencies to be declared upfront, and then all deep dependencies are requested in parallel with the module request

Re: Detecting a Module object

On Feb 21, 2014, at 3:53 AM, Guy Bedford wrote: Being able to do `m instanceof Module` is certainly a lot nicer here though. Just to return to the consideration of modules as classes, I still don't understand what the major issue is with having a module as a class without any prototype

Re: Module Shimming

On 1 April 2014 11:08, Jacob Gable jacob.ga...@gmail.com wrote: I was wondering if anyone has any thoughts/approaches on shimming non ES6 modules. I've run into two different approaches so far and there doesn't seem to be much guidance around the process. To be clear, all I'm talking about

Re: Detecting a Module object

Being able to do `m instanceof Module` is certainly a lot nicer here though. Just to return to the consideration of modules as classes, I still don't understand what the major issue is with having a module as a class without any prototype methods. On 21 February 2014 00:07, Guy Bedford guybedf

Detecting a Module object

If Module objects are not classes, then what would be the recommended way to detect if a given object is a Module? Would there be a unique toString output? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Detecting a Module object

February 2014 22:31, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Feb 20, 2014, at 11:47 AM, Guy Bedford wrote: If Module objects are not classes, then what would be the recommended way to detect if a given object is a Module? Would there be a unique toString output? Can't. 'toString

Re: Detecting a Module object

, Feb 20, 2014 at 1:01 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Feb 20, 2014, at 12:53 PM, Guy Bedford wrote: Thanks, if there is some way to detect this it may well be useful. The use case I came across it was trying to allow ES6 modules to be transpiled into AMD for use

Re: System.import FTW

On 14 February 2014 14:13, C. Scott Ananian ecmascr...@cscott.net wrote: Can someone point me to the spec for `System.import`? It's in the ES6 specification draft under Loader.prototype.import - https://people.mozilla.org/~jorendorff/es6-draft.html#sec-loader.prototype.import .

Re: Modules loader define method

Surely this can be dealt with by extending the CSP policy to allow script domains which are able to call System.define. Surely it is an equivalent permission to being able to load script from the domain anyway, when it is restricted to running in the outer scope only? On 31 October 2013 16:10,

Re: Modules loader define method

wrote: I think I must be missing something? On Fri, Nov 1, 2013 at 6:47 AM, Guy Bedford guybedf...@googlemail.comwrote: Surely this can be dealt with by extending the CSP policy to allow script domains which are able to call System.define. How is that different to extending the CSP policy

Module Loaders - module declarations in builds

I'm in the process of matching up an ES6 module loader with AMD support to the RequireJS tests, and have a question on concatenated module files. If I have a module, foo.js, which defines its own name and its dependencies: foo.js: module 'foo' { export var p = 'value'; } module

Re: Module Loaders - module declarations in builds

On Wed, Jul 31, 2013 at 3:05 AM, Guy Bedford guybedf...@googlemail.com wrote: I'm in the process of matching up an ES6 module loader with AMD support to the RequireJS tests, and have a question on concatenated module files. If I have a module, foo.js, which defines its own name and its

Re: Module Loaders - module declarations in builds

request to the module itself. Surely this is the most fundamental use case for modules providing the multiplexing support of dependencies? Guy On 31 July 2013 10:53, Guy Bedford guybedf...@googlemail.com wrote: Ok sure, while I understand nesting is no longer supported, it could potentially still

Module loader dependency trees

Hi, One very useful feature in RequireJS is the ability to hook into the dependency tree through the onResourceLoad API. Currently, the way the link function is designed for ES6 modules, there is no way for a loader to discover the imports for a given module. If there was some way to allow some

Modules Loader.load function

I see there are now two load functions for the ES6 module loader - 'Loader.import' and 'Loader.load'. Loader.import seems to apply the full normalization process, while Loader.load takes a url directly. This sounds like a good feature to me. From the code comments in the reference loader at

Re: Custom module loaders and script tags

, 2013 at 11:29 PM, Guy Bedford guybedf...@googlemail.com wrote: I'm trying to work out how custom module loaders can be used with standard script tags. For example, say I create a RequireJS-style loader (with an identical configuration API including map config etc), and want to use

Re: Custom module loaders and script tags

in many cases. On 8 June 2013 12:58, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Sat, Jun 8, 2013 at 3:56 PM, Guy Bedford guybedf...@googlemail.com wrote: Would it be better simply to override the default system loader, or would this be discouraged? I notice Yehuda's examples