Backport template compiler improvements from 5.x - #673
Merged
Conversation
The template compiler contents have to be evaluated separately for each addon in the build pipeline. If they are **not** the AST plugins from one addon leak through to other addons (or the app). This issue led us to attempt to purge the normal node require cache (the `purgeModule` code). This works (and has been in use for quite a while) but causes a non-trivial amount of memory overhead since each of the addons' ends up with a separate template compiler. This prevents JIT'ing and it causes the source code of the template compiler itself to be in memory many many many times (non-trivially increasing memory pressure). Migrating to `vm.Script` and sandboxed contexts (similar to what is done in FastBoot) resolves both of those issues. The script itself is cached and not reevaluated each time (removing the memory pressure issues) and the JIT information of the script context is also shared. Thanks to @krisselden for pointing out this improvement! (cherry picked from commit 8d5dbcf)
(cherry picked from commit 47041c9)
These APIs force Ember to use global mutable state (the list of plugins) and require some pretty gnarly cache busting techniques to avoid having addons break each other (due to the global mutable state leaking from one addon to another). In order to discourage this mutable state issue, Ember has deprecated usage of `Ember.HTMLBars.registerPlugin` and `Ember.HTMLBars.unregisterPlugin` (as of Ember 3.27). This PR changes all invocations to pass the required AST transforms directly in to the compiler invocation (instead of calling `registerPlugin` before hand), and allows us to continue working properly while avoiding the deprecation (and that evil mutable state). (cherry picked from commit 1c813dc)
Node 12+ has access to `globalThis` (including within a VM context), but older versions do not. Due to the detection done in https://git.io/Jtb7s, when we can't find `globalThis` (and don't define `global` global) evaluating `ember-template-compiler.js` throws an error "unable to locate global object". This ensures that either `globalThis` or `global` are defined. (cherry picked from commit 957dbc6)
We have to reverse these for reasons that are a bit bonkers. The initial version of this system used `registeredPlugin` from `ember-template-compiler.js` to set up these plugins (because Ember ~ 1.13 only had `registerPlugin`, and there was no way to pass plugins directly to the call to `compile`/`precompile`). Calling `registerPlugin` unfortunately **inverted** the order of plugins (it essentially did `PLUGINS = [plugin, ...PLUGINS]`). Sooooooo...... we are forced to maintain that **absolutely bonkers** ordering. (cherry picked from commit d8e5dda)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
purgeModulecache busting withvmbased sandboxingReferences:
purgeModulecache busting withvmbased sandboxing #660