New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dynamic importing of CodeMirror modes at runtime #4764
Conversation
app/src/highlighter/index.ts
Outdated
* is idempotent and can be called multiple times with no adverse | ||
* effect. | ||
*/ | ||
readonly require: () => Promise<void> |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
@niik As I can understand this will change the way for someone to add support for a new programming language? So the docs need to be updated as well in this PR? 🤔 |
app/src/highlighter/index.ts
Outdated
@@ -162,6 +292,14 @@ function detectMode(request: IHighlightRequest): CodeMirror.Mode<{}> | null { | |||
return null | |||
} | |||
|
|||
const modeDefinition = mimeModeMap.get(mimeType) | |||
|
|||
if (!modeDefinition) { |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
app/src/highlighter/index.ts
Outdated
* is idempotent and can be called multiple times with no adverse | ||
* effect. | ||
*/ | ||
readonly require: () => Promise<void> |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
@say25 I probably won't get a chance to start reviewing it until next week |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this change how community members can add additional languages? If so, could we also get the docs updated to reflect the new way of adding language support?
I don't believe we have any docs that goes into the specifics of how to add a new language. I assume that contributors who've added a theme have probably just copied and pasted a previous mode that was already in the |
Ready for another look 🙇 |
When we initially shipped syntax highlighted diffs we supported 18 languages and formats. Since then and thanks to community contributions the list has grown to 36 with more on the way.
As the list of supported languages has grown so has the bundle size of the highlighter module and it sits at about 0.5Mb (unminimized) at the moment. Since that file has to be loaded, parsed, and initialized for each highlighter web worker we spin up (in normal usage 2 for the life time of the application) this creates unnecessary overhead when most users rarely combine more than a few languages in their day to day work.
This PR leverages chunk splitting in webpack 4 to split out each language (or technically each CodeMirror mode) into its own, separate javascript file that then gets loaded, at runtime, when that particular language mode is needed through the
importScript
web worker call.This ultimately leads to less code being loaded into the runtime and faster initial highlighting. Instead of loading 0.5Mb we're now loading the bare minimum (~16kb) plus whatever mode is required.
Highlighter bundle before
Highlighter bundle after
Performance
Essentially we sacrifice a little bit (in absolute numbers) of performance whenever a new language is loaded in exchaneg for a big gain in initial load time and zero overhead of adding new language modes in the future. These timings are all taken in dev mode on my early 2015 macbook 12"