Allow use conditional directives at least within the section of the import/export directives about dep-configured-imports HOT 5 OPEN

This is effectively a separate proposal, so I don't think it belongs here as a bug.

from dep-configured-imports.

This is an alternative to the proposal.
I do not think that the main purpose of the "configured-imports" is just to have them as they are proposed here.
The main reason is satisfy the requirement to "import by condition".
What means word "configured" in your proposal?
Condition directives allows "to configure imports".
I don't think that your proposal have some advantages over the "conditional directives".
Parsing constant expression in the directive is not harder than parsing that what you propose.
I am talk about the multi-branch analysing.
If analyzer detect an unknown identifiers and a compared values then it also can warn about that.

Eg.

#if some_predefined_id == expected_literal
#endif

No problem. If analyzer cannot recognize a "predefined_id" as an identifier that it expected to find here then it can send warning "Cannot recognize id. Analysys would not be performed for this condition".

from dep-configured-imports.

I can wrote it for you if don't know how to implement it.
I am about the detection of "multi-branching" for Dart analyzer.
You should only specify the proposed identifier, their values and what this combination means.

Eg.

dart.platform:
  values:
   "browser" # Browser engine
   "server" # Server engine
dart.vm:
  true: # Dart VM present, maybe in the browser
  false: # Not native engine, maybe javascript

from dep-configured-imports.

We could allow compound conditions in the import.
If we also have conditional exports, it's not technically necessary since you can import something if test1 && test2 by using test1 to conditionally import something that uses test2 to conditionally export what we want. It requires more library files, but it is possible.
The problem with expressions is that it's hard to stop. Using "!", "&&" and "||" to combine tests and parentheses to group them is an easy extension to this proposal, but to begin with, I'd like to keep things simple. If you have a complex condition for importing a library, there might be an abstraction missing somewhere.

from dep-configured-imports.

Is there some agreement what values are available for the comparsion in the expression?
Somewhere features where mentioned, is this still part of this DEP?
I poked around in some Ruby code a few days ago, they have a lot of if version >= x ...
If it is only platform, the mentioned operators should do.
Of course someone could still demand other operations like platform.startsWith('xxx'), platform.contains((math.pi * 42).toString()), ... or even http.get()...contains(...) ;-)

from dep-configured-imports.