The library is added in devtools/client/shared/vendor, like the other third-party
libraries we use in DevTools.
This was the latest file that justified the debugger-specific vendor machinery,
so we can clean that up now.
First, we can remove the vendor.js file.
With this, this means that bin/bundle.js now only bundles the workers, using rollup,
so we can remove webpack and its associated packages from package.json, as well
as the webpack.config.js.
Finally, we can stop handling debugger vendors in build-debugger.js
Differential Revision: https://phabricator.services.mozilla.com/D193916
This is not used anymore, so we can drop it.
This was the only vendored item that was contributing
to vendor.css, so we can delete the file, and cleanup
our webpack config.
Differential Revision: https://phabricator.services.mozilla.com/D193915
The library was only used to make the quick search panel
and the shortcut modal to show with a slide-in animation.
This can be replaced with a simple CSS animation instead.
I'm taking this as an opportunity to cleanup a few things
that were unecessary or not ideal in the CSS file.
Differential Revision: https://phabricator.services.mozilla.com/D192266
Computing the expression would involve calling Babel's `generate` method on the AST node,
which is expansive. But we rarely read this attribute.
Differential Revision: https://phabricator.services.mozilla.com/D190179
We were creating them and later filtering them out.
Also `getUniqueIdentifiers` was duplicating a possibly 100M+ large array...
Differential Revision: https://phabricator.services.mozilla.com/D190177
On bug 1843454 STR, symbols.identifiers is a 100M large array.
So all these intermediate array cause a serious amount of short-lived arrays.
Differential Revision: https://phabricator.services.mozilla.com/D190176
As `callExpressions` are only used for knowing if that's a react module...
We could avoid a bunch of intermediate objects by computing right away if we have a react import.
Differential Revision: https://phabricator.services.mozilla.com/D190782
As `imports` are only used for knowing if that's a react module...
We could avoid a bunch of intermediate objects by computing right away if we have a react import.
Differential Revision: https://phabricator.services.mozilla.com/D190781
These three attributes are very large arrays and we could easily keep them
within the worker thread by exposing new dedicated method.
Differential Revision: https://phabricator.services.mozilla.com/D187436
Clarify which attributes are used only within the worker
and shouldn't be passed to the main thread.
Also clarify what are the usages of each attribute so that we can
more easily transfer some on-demand.
`callExpressions` wasn't used anywhere.
Differential Revision: https://phabricator.services.mozilla.com/D187401
This is needed to handle the new Regexp `v` flag.
I'm taking this as an opportunity to fix a couple issue in the bundle script.
Differential Revision: https://phabricator.services.mozilla.com/D180675
Instead clear per removed thread so that state of the previous page
doesn't get cleared as the navigation of the next page starts.
This will also be useful for service worker debugging.
Differential Revision: https://phabricator.services.mozilla.com/D179941
Now location objects are slightly different between SourceMapLoader and Debugger frontend.
SourceMapLoader doesn't make any use of the source objects, so I only pass `sourceId`.
This will reduce the amount of data transferred between the main thread and source-map worker.
But this requires mapping location objects in and out of the source map worker.
We were already mapping location objects returned by the worker in order to lookup
for the related source object.
Also make SourceMapLoader return null when the location doesn't map,
so that it is easier to identify when it doesn't map and prevent having to do:
`originalLocation.sourceId == location.sourceId`.
Differential Revision: https://phabricator.services.mozilla.com/D178397
Now location objects are slightly different between SourceMapLoader and Debugger frontend.
SourceMapLoader doesn't make any use of the source objects, so I only pass `sourceId`.
This will reduce the amount of data transferred between the main thread and source-map worker.
But this requires mapping location objects in and out of the source map worker.
We were already mapping location objects returned by the worker in order to lookup
for the related source object.
Also make SourceMapLoader return null when the location doesn't map,
so that it is easier to identify when it doesn't map and prevent having to do:
`originalLocation.sourceId == location.sourceId`.
Differential Revision: https://phabricator.services.mozilla.com/D178397
Now location objects are slightly different between SourceMapLoader and Debugger frontend.
SourceMapLoader doesn't make any use of the source objects, so I only pass `sourceId`.
This will reduce the amount of data transferred between the main thread and source-map worker.
But this requires mapping location objects in and out of the source map worker.
We were already mapping location objects returned by the worker in order to lookup
for the related source object.
Also make SourceMapLoader return null when the location doesn't map,
so that it is easier to identify when it doesn't map and prevent having to do:
`originalLocation.sourceId == location.sourceId`.
Differential Revision: https://phabricator.services.mozilla.com/D178397
When dealing with a `(` token, we check the next tokens to find the matching
closing paren. In the same time, we compute the length of all the tokens inside
the paren.
If we reach a given length (60 at the moment) without finding the closing paren,
we consider it "long" and will treat it (and the closing paren) as line delimiter.
On top of that, we expand line delimiters to `||` and `&&` when there not in a
"short" paren, so we can split up long lines.
Differential Revision: https://phabricator.services.mozilla.com/D175477
When dealing with a `(` token, we check the next tokens to find the matching
closing paren. In the same time, we compute the length of all the tokens inside
the paren.
If we reach a given length (60 at the moment) without finding the closing paren,
we consider it "long" and will treat it (and the closing paren) as line delimiter.
On top of that, we expand line delimiters to `||` and `&&` when there not in a
"short" paren, so we can split up long lines.
Differential Revision: https://phabricator.services.mozilla.com/D175477
Nicolas Chevobbe