Add precompile support?

[acrazing]

• We often use process.env.XXX to judge current compile environment is production or development (see follow code), this is same to c/c++ precompile, too many things could be simplified!

  // currently: use envify to handle this:
  if(process.env.NODE_ENV === 'production') {
    // do something
  }
  
  // use precompile: auto remove block if not true or replace with block if true
  #define NODE_ENV production
  #if NODE_ENV == production
    // do something
  #endif

• Some functions just transform const to const, this could be done in compile, rather than in runtime, for example:

  function array2map<T>(data: T[], keyField: string = 'id'): { [key: string]: T } {
    const out: { [key: string]: T } = {}
    data.forEach((item) => out[(item as any)[keyField]] = item)
    return out
  }
  
  const options = [
    {
      name: 'Option A',
      value: 'A',
    },
    {
      name: 'Option B',
      value: 'B',
    }
  ]
  const optionsMap = arrray2map(options)
  // currently, we can only run this in runtime,
  // but this just transform one const to another const,
  // this completely could be done in compilation phase.

[yortus]

For your first point, there are already open issues like #4691.

For your second point, it is certainly useful to be able to do arbitrary computations at compile-time using the same source code (I believe D supports this). Not sure it will get much support here though. The compiler would have to actually execute the code to get the results, which would make the compiler pretty unstable given the many footguns of JS. For example if your array2Map had a bug in it, the compiler may never halt and not even give you an error message.

[RyanCavanaugh]

Duplicate on the first point as noted.

The second part is not the sort of thing we'd ever want to get into. It's much, much too complex relative to good solutions available today and the actual gain you'd get in runtime performance in the majority of scenarios.