Design an Ecosystem Compatible way for Writing Prepack Specific Branches

[sebmarkbage]

It is useful to be able to write library code that takes a different path if you know that you're running a Prepack environment and can rely on that code getting pre-evaluated.

let fn = function() { ... };
if (__PREPACK__) {
  fn = function() { ... };
}

Right now it is not palatable for libraries (such as React) to publish such code to NPM. Because you can't rely on this being properly stripped out by other build tool chains.

A common pattern is to strip out patterns like:

if (process.env.NODE_ENV !== 'production') { ... }

It might be possible to have a Prepack specific one like:

if (process.env.NODE_ENV === 'prepack-production') { ... }

However, Prepack would then have to special case things like process.env.NODE_ENV !== 'production' to also fail! This is weird.

Another strategy might be something like:

if (false && __PREPACK__) {
}

Other constant folders/minifiers would automatically strip out this branch but we could detect it as a special case and make that branch pass.

Another problem to consider is if minifiers run before Prepack in the build steps, then none of this works.

This is a rabbit hole that needs a solution.

See similar discussion about introducing a "profile" build of React. facebook/react#6627

[hermanventer]

We already have a number of properties that are only available if running with Prepack, for example __abstract. PREPACK would be no different.

Our hack to get around tools that do not understand these properties is to do "if (global.__abstract) {...} else {...}.

[sebmarkbage]

@hermanventer The problem is that if I add that to any existing codebase, it won't get stripped out and the bytes gets shipped on the network and parsed/compiled/evaluated at init time. For libraries that hunt individual bytes to strip out for optimal download, that's a big deal.

[hermanventer]

Since global.__abstract is undefined, one could hope that a minifier will constant fold it away. Am I being way too optimistic about the state of the art?

[sebmarkbage]

It can if you explicitly opt in to those particular properties being undefined otherwise it can't assume that it is because it could be a new browser feature. The state of the art doesn't assume anything about what it doesn't know about. The problem is making everyone reconfigure their toolchains to add our names to that list.

Btw, we're also claiming all our names on the global namespace forever because if people ship with this detection in browsers, then if browsers want to add this name later for some other use case, then they can't because the detection code would pass and they would break the existing web.

See __defineGetter__ and __proto__ for examples with similar names that have been added.