I now check the size of the page bundle against previous versions before publishing to alert me to any potential unintended dependencies that are being bundled. This means that special care needs to be taken to make sure that the injected bundle does not interact in surprising ways with the rest of the web page (such as interacting correctly with Symbol.observable polyfills and not importing React).
REDUX DEV TOOLS CODE
I am also now vetting the page bundle that is injected into each page more carefully since this code gets run in the same context as web pages. If I had any suspicion that the changes I made would have caused problems I would not have released the change.
REDUX DEV TOOLS MANUAL
Each and every release is run through a number of automated and manual tests on each browser to prevent regressions. To be clear, I take my work on the Redux DevTools very seriously. Next steps How does Redux DevTools prevent this from happening again? This method for importing Underscore was removed in AUI v8.0.0 (released ), however it appears that some parts of Jira depend on AUI v6.0.5 (released ) where this non-ideal way of importing Underscore is still in production. Note that this code is found in AUI (the Atlassian User Interface library).
Since window._ is set to the Lodash library by the Redux DevTools extension, Jira sees that window._ is already set and exports the Lodash library thinking that it’s the Underscore library. Okay, but why does having window._ being set to the Lodash library cause problems for Jira? It’s because Jira uses Underscore and this is how it’s imported:
There is an open issue on the Lodash repository to address this situation. I would expect most libraries these days to point to a CommonJS build and expose the UMD build in a separate field. Little did I know that the main field of lodash still points to a UMD build which sets window._ to the Lodash library. (I now know that the former way of importing Lodash is recommended for smaller bundles.) I thought this was the more common way to import Lodash anyway and that there wouldn’t be any dangerous side effects by importing it through the main entry point. Why was this change made? I’ve recently been trying to avoid “deep imports” as a general rule since the new exports field used by Webpack disallows any deep imports that are not explicitly defined.
import identity from 'lodash/identity' import mapValues from 'lodash/mapValues'
0 kommentar(er)
