Loose idea on "try import"

# Michał Wadas (18 days ago)

Syntax:

try import fs from 'fs' else import fs from 'fs-polyfill' else import fs from 'another-fs-polyfill' else do nothing; // Not sure about syntax

try import {watchDirectory} from 'fs' else import {watchDirectory} from 'fs-polyfill' else if(process.os === 'ExoticSystem') import {watchDirectory} from 'another-fs-polyfill' else throw Error('Your OS doesn't support watching directories');

Usages:

  • Optional dependencies
  • Polyfills

Problems:

  • This can prevent loading modules before execution if presence of modules can't be proved statically
  • else-if requires execution before loading module - can be dropped

I don't have enough time and knowledge about modules to write actual proposal.

# Herby Vojčík (18 days ago)

On 1. 3. 2019 12:04, Michał Wadas wrote:

Syntax:

try import fs from 'fs'    else import fs from 'fs-polyfill'    else import fs from 'another-fs-polyfill'    else do nothing; // Not sure about syntax

try import {watchDirectory} from 'fs'    else import {watchDirectory} from 'fs-polyfill'    else if(process.os === 'ExoticSystem') import {watchDirectory} from 'another-fs-polyfill'    else throw Error('Your OS doesn't support watching directories');

I am not an expert, but afaict ES module system was created to be statically analysable and this bring uncertainity.

For that probably dynamic import() is there; and your usage should await for a promise that tries to load one then the other etc.

# Michał Wadas (18 days ago)

I don't think so, because:

  • Using promises to import module is not always desirable
  • This mechanism doesn't impact ability to statically analyze modules if ifs are excluded - it can only increase resolution time.
# Andrea Giammarchi (18 days ago)

honestly this look like an or would've been great as reserved

try import fs from 'fs' or import fs from 'fs-polyfill' or import fs from 'another-fs-polyfill' catch optional, and triggered only if previous 3 imports failed finally optionally do something;

# Herby Vojčík (18 days ago)

On 1. 3. 2019 18:35, Michał Wadas wrote:

I don't think so, because:

  • Using promises to import module is not always desirable
  • This mechanism doesn't impact ability to statically analyze modules if ifs are excluded - it can only increase resolution time.

Yeah, if 'if's are excluded. That version with those ifs was what was concerning. That actually needs runtime to do the work. I suppose until it doesn't need the runtime, it's all ok.

# Ben Wiley (18 days ago)

Has anyone seen anything like this done in another language (with static imports)? If so we could learn something maybe. I know you can conditionally import in Python but that's basically the same thing as .catch()ing dynamic import()s in JavaScript (except done synchronously).

Ben

Le ven. 1 mars 2019 15 h 26, Herby Vojčík <herby at mailbox.sk> a écrit :

# Isiah Meadows (18 days ago)

Personally, I find this a bad idea. Top-level await in modules would solve this problem far more quickly and efficiently.


Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com