[rewrite: bundler] Proposal: add #if / #ifdef MACRO preprocessor

[futurist]

Description:

The bundler can add #if or #ifdef MACRO preprocessor support like C

This way it's good for custom building according to some switch on / off

Think adding a LEGACY swich, to make the bundler build with IE8 support, or some other things

Steps to Reproduce:

#ifdef LEGACY
    // build for IE8+
    if (value instanceof Array) { ...
#else
    // build for Mordern
    if (Array.isArray(value)) { ....
#endif

Expected:

The #if statements can work as the similar behavior as C preprocessor does.

The LEGACY value can from ENV / command line switch / some file.

The bundler can judge whether to include the block into the bundling code, according to the condition.

Actual:

N/A

[futurist]

I've found below lib maybe working with this feature:

https://github.com/dcodeIO/Preprocessor.js

https://github.com/ParksProjets/C-Preprocessor

But both have a large code base

[pygy]

Your exact proposal will most likely be rejected because it would break the test suite and non-bundler use (via, say Browserify).

This issue may however be reframed as a IE8 compatibility feature request.

As already discussed, language-wise, the only non-polyfillable ie8 incompatibilities in Mithril itself is the use of someString[x] instead of someString.charAt(x). The use of the DOM APIs would also need a review to see if they are polyfillable...

The test suite, however uses getters/setters:

• for the DOM mocks (which may or may), so, even if you get Mithril to run, you won't be able to test it.
• for the browser-side require polyfill.

Both issues could be worked around, but it won't be trivial.

Once it's done, the mocks may need some tuning if you want to them to emulate potential ie8 quirks as well.

[futurist]

It's not only for IE8, just make the bundler be switchable for code features.

It's maybe considered for future plan of mithril feature sets and compatibility.

The tests and non-bundler use can be solved, just add a more step: preprocessor

This feature makes mithril as a swichable lib, for each module.

[pygy]

So you'd need an additional build step when working on files that need to be preprocessed (in order to run the test suite, for example)?

I supposed we may also need to add custom, per build-type tests. Assuming n build-time options that are not mutually exclusive, we'd end up with 2^n possible builds...

[lhorie]

wouldn't it make more sense to create plugins for a compiler toolchain like babel? It's less likely to introduce uncontrolled regressions and it's far easier to test

[futurist]

Yes that really make sense. But seems to be a bigger one?

Think of all the AST parser / transformer / generator things

Or just using babel directly? (I know somebody may hate/avoid it 😄 )

[lhorie]

Well, I'm not really planning on adding that much preprocessor complexity into the repo, but if e.g. the Array.isArray => instanceof Array transformation is important enough for you, you could make that transformation on your output code