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

2020-07-16 Thread Herby Vojčík
On 16. 7. 2020 15:23, Guy Bedford wrote: 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

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

2020-07-16 Thread Andrea Giammarchi
On a second thought ... couldn't `import.meta.cache`, or something similar, be implemented in NodeJS only? On Thu, Jul 16, 2020 at 3:44 PM Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > FWIW explicit eviction is not only fine, if you own the code that does > that, but the only way I

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

2020-07-16 Thread Andrea Giammarchi
FWIW explicit eviction is not only fine, if you own the code that does that, but the only way I can code cover 100% all the branches of my libraries. The issue here is the untrusted Web, where I'd never expect any 3rd parts library to evict a module I am using within my code ... like ... ever.

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

2020-07-16 Thread Guy Bedford
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: [Proposal] Allow rest parameter on try... catch

2020-07-16 Thread Michaël Rouges
Yeah, `Promise.allSettled` is better than `Promise.all()` for that... but, perhaps, it can be useful to improve it to provide a way to enforce the fulfillment OR to catch only the errors if any, but the real idea is to have a way to handle the errors, using a `try... catch(...errors)` or a