There previously were two special files that were handled
by `build_release_applications`: root.js and RuntimeInstantiator.js.
Both files are explicitly part of the startup process of DevTools
and its various entrypoints.
To remove the copying from `build_release_applications`, we have
to move these to the relevant `devtools_entrypoint`. Since a
`devtools_entrypoints` bundles all subdirectories, we can't keep
these files in `front_end/` directly. Instead, we move these files
to `startup/` to denote their special-casing in the startup process.
Next to that, we have to fix all usages of these files in the entrypoints.
For all JavaScript entrypoint files, all side-effect legacy files
that are loaded by `startup.js` (previously known as `root.js` and renamed
to prevent confusion with the `root/` module) are removed. All
"additional" legacy files that a particular entrypoint requires are
still loaded as-is.
The RuntimeInstantiator is moved to become an implementation detail
of `startup/`. Therefore, all of the usages that were previously
importing from `RuntimeInstantiator` now import via `startup.js`.
In the end, the special-casing of these files are removed and renamed
for clarity. In the future, we want to remove the complicated
entrypoints startup process, but we are not ready for that yet.
That will require additional cleanups with `resources` in `module.json`
before that change can happen.
R=aerotwist@chromium.org
Bug: 1131500
Change-Id: I198d5a62d2aab70f842c68d9b4c0871fde1587a4
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2485072
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
To continue to move away from `build_release_applications.py`, move
building `common-legacy.js` into `devtools_entrypoint`. In the end,
it will allow us to remove `_rollup_module` from
`build_release_applications.py`.
The logic in `build_release_applications.py` is updated to assume
a pregenerated `-legacy.js` file based on the `pre_generates_legacy`
option in the `module.json` file. Once all `-legacy.js are migrated,
we can remove this option once again.
To make sure that we Rollup properly, we should assume that an
entrypoint in the same folder is regarded as external. Otherwise,
we would rollup the contents of `common.js` into `common-legacy.js`,
which is not what we want.
R=aerotwist@chromium.org
Bug: 1131500
Change-Id: Idcda3e1c2436a0bebb36501523c8d586d6e86fac
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2450297
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
For all `_module.js` files, we currently copy all `modules` into
the `module.json` metadata. However, since then the Runtime got
updated to always load the entrypoint. This is possible, because
in release modes only the entrypoint exists and all other files
are removed.
Therefore, we can use an empty array to denote that solely the
entrypoint should be loaded by the Runtime. If however the module
has a legacy file, the Runtime needs to load that instead. (See
`Runtime._loadModules` for more information) Therefore, include
solely the legacy file to the metadata information in the
`_module.js` to load it.
Eventually, this will allow us to remove the files from the modules
array in the `module.json`, as only Closure would require that
information.
R=aerotwist@chromium.org
Bug: 1131500
Change-Id: Ie14bd55b29b356a39aad7e8ca2041c979bd1b2cb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2461783
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
A recent TS config change elsewhere had caused these tests not to
compile with the error of:
```
error TS6307: File '/Users/jacktfranklin/src/devtools/devtools-frontend/scripts/component_bridges/value_for_type_node.ts' is not listed within the file list of project '/Users/jacktfranklin/src/devtools/devtools-frontend/test/unittests/scripts/component_bridges/tsconfig.json'.
```
The fix is to mark the dependency from the unit tests as a TS project
reference, and then generate output in the same place as the source, so
that import paths don't need to change.
This isn't ideal, and we would use ts_library if doing this now, but
this code pre-dates ts_library and also is only going to be around for
the length of the TypeScriptification work, so it doesn't feel worth the
effort to restructure it.
Change-Id: I9a924bf3e2ed945dd22ce233eda2c8c15f3193c6
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2466188
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Root cause:
i18n is designed to work with strings that are declared in a UIStrings
object on the SAME file where they are being used. To my best knowledge
this is done to improve performance when searching for a translation,
but in Devtools there are strings that live in module.json files and
are exposed to i18n via a ModuleUIStrings.js file.
Fix:
There is already a mechanism for this kind of templating in the i18n
library which exposes a small subset of translations that match a
specific pattern, the fix is to change this pattern to match
ModuleUIStrings and to also include this as part of the translation
resolution.
Change-Id: If44a84a9b5892558bf832e6d08ea36d1a8f4ddd1
Bug: 1136655
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2459638
Commit-Queue: Vidal Diazleal <vidorteg@microsoft.com>
Reviewed-by: Simon Zünd <szuend@chromium.org>
The current behavior enforces that the second argument passed to all
i18n.getLocalizedString is part of UIStrings structure, this is not
possible to enforce in the current shape as a reference is also a valid
scenario
-------- e.g-----------
const title1 = UIStrings.title1;
const title2 = UIStrings.title2;
function render(title) { i18n.getLocalizedString(str, title) }
-------- end e.g-----------
Also minor fix in the naming convention of the file (localizationV2checks)
Change-Id: I9e7536850f7bbb73b2e27f5906343b3b1dbfd82d
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2451369
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Christy Chen <chrche@microsoft.com>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Vidal Diazleal <vidorteg@microsoft.com>
This CL addresses a few issues that will help make it possible
to build Chromium using Python 3.
Nothing in this CL should cause any functional changes, and
Python 3 is not required (indeed, won't even work yet), but
this CL will be needed to unblock other work.
See https://crrev.com/c/2333868 for the roll-up Chromium patch,
which also has multiple other dependencies.
Bug: 1112471
Change-Id: Ica8a5b2b24674e1abd267bcd558b7101a6da6fc5
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2330718
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Dirk Pranke <dpranke@google.com>
It's clearer if a component's data setter is defined as:
set data(data: Foo)
Rather than:
set data(data: { x: string, y: number, ...})
And also has some advantages in that you can easily re-use the interface if you
define `get data`, and that you can use this type in Closure land if you need
to. So we are now enforcing at the component bridges level that each `set data`
follows this pattern.
This is part of a larger piece of work to ensure efficient DOM updates, because
exposing the interface like this lets us use it in a component's render code to
tell TypeScript how to type `.data=${{...}}` within lit-html.
Bug: 1129881
Change-Id: Ib8bbe5682acfed371d5afccc31727623167b1fdb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2422949
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Since formatter_worker.ts is the actual entrypoint for the worker,
we should perform the message handling and postMessage invocations
there. This allows us to remove accesses to the `self.postMessage`
global in the implementation of the parsers and formatters, allowing
proper unit testing. Note all `self.postMessage`s have been removed,
as that requires additional refactoring in a follow-up CL.
This also paves the way for removing `formatter_worker_entrypoint`,
which is currently a no-op file. That requires additional infrastructure
changes to `Common.Worker` to allow specify a subfolder of `front_end/`
to be passed as the entrypoint.
Note that this CL also removes the `parseSCSS` method, which appears to
be unused in both the Chromium codebase as well as externally. Testing
on stable shows that we are currently not formatting `.scss` files
anyways.
R=aerotwist@chromium.org
Bug: 1011811
Change-Id: I808c5ea83efa5ec9fed6bd1aec2418487f553848
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2410232
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
This reverts commit 862107080d.
Reason for revert: Chromium build issue fixed.
Original change's description:
> Revert "Reland "Remove support for remote modules""
>
> This reverts commit b3859e8d65.
>
> Reason for revert: Breaking roll (https://ci.chromium.org/p/chromium/builders/ci/win-archive-rel/17700)
>
> Original change's description:
> > Reland "Remove support for remote modules"
> >
> > This reverts commit d5044ddf05.
> >
> > Reason for revert: Fixed Chromium debug issue.
> >
> > Original change's description:
> > > Revert "Remove support for remote modules"
> > >
> > > This reverts commit 419c91eff6.
> > >
> > > Reason for revert: Breaks roll https://chromium-review.googlesource.com/c/chromium/src/+/2416805
> > >
> > > Original change's description:
> > > > Remove support for remote modules
> > > >
> > > > LightHouse is currently broken in Canary, because of problems with
> > > > the appspot server. This isn't the first occurrence of this problem
> > > > and it becomes increasingly more difficult to figure out why the
> > > > server keeps on breaking. This is combined with a large infrastructure
> > > > cost of supporting remote modules and a confusing debugging experience
> > > > when working with it locally.
> > > >
> > > > The reason we had remote modules was the fact that these modules are
> > > > too large to be included in the Chromium bundle. In the last months,
> > > > we have made numerous remote modules bundled, by applying minifications
> > > > and optimizations to each module.
> > > >
> > > > The remaining remote module that we are currently shipping is LightHouse.
> > > > Since the remote appspot server is broken and unlikely to be fixed
> > > > anytime soon, now is the best time to finally resolve the remote
> > > > modules question.
> > > >
> > > > Therefore, we remove support for remote modules from the `module.json`
> > > > files and `Runtime.js`. Additionally, we update the build system
> > > > to properly generate the required files and load them via ES modules.
> > > >
> > > > We will be able to perform subsequent cleanups in the Runtime to remove
> > > > more infrastructure related to scripts/remote modules, but given that
> > > > this CL is already quite large we are doing that in a follow-up CL.
> > > >
> > > > Follow-up action items for the LightHouse folks are to further decrease
> > > > the bundle size for LightHouse. Since we are now loading it via ES
> > > > modules, we can now use ES imports in the `devtools-dt-bundle.js` as
> > > > well. This allows us to remove the copy of the SDK files, as well as
> > > > make use of proper ES exports, rather than the browserified requires.
> > > >
> > > > R=aerotwist@chromium.org,yangguo@chromium.org,paulirish@chromium.org
> > > >
> > > > Fixed: 1128890
> > > > Change-Id: Ib4271a8064b18d31b75d9e28dbe5e3cb3c77d7ff
> > > > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416511
> > > > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> > > > Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
> > >
> > > TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org
> > >
> > > Change-Id: I9d3da08108a35d7dadeefd526ea9dbd562ad3432
> > > No-Presubmit: true
> > > No-Tree-Checks: true
> > > No-Try: true
> > > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416519
> > > Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
> > > Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
> >
> > Change-Id: I26bf0565297c8e167039362b30109d7020bbca56
> > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418431
> > Commit-Queue: Paul Lewis <aerotwist@chromium.org>
> > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
>
> TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org,alexrudenko@chromium.org
>
> Change-Id: I0ed24d32c9b68bc4cb8026f6fc362540800beeb0
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418408
> Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Change-Id: I8718e9d94c384a13fd18261f8f497d32418658fb
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2421690
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This reverts commit b3859e8d65.
Reason for revert: Breaking roll (https://ci.chromium.org/p/chromium/builders/ci/win-archive-rel/17700)
Original change's description:
> Reland "Remove support for remote modules"
>
> This reverts commit d5044ddf05.
>
> Reason for revert: Fixed Chromium debug issue.
>
> Original change's description:
> > Revert "Remove support for remote modules"
> >
> > This reverts commit 419c91eff6.
> >
> > Reason for revert: Breaks roll https://chromium-review.googlesource.com/c/chromium/src/+/2416805
> >
> > Original change's description:
> > > Remove support for remote modules
> > >
> > > LightHouse is currently broken in Canary, because of problems with
> > > the appspot server. This isn't the first occurrence of this problem
> > > and it becomes increasingly more difficult to figure out why the
> > > server keeps on breaking. This is combined with a large infrastructure
> > > cost of supporting remote modules and a confusing debugging experience
> > > when working with it locally.
> > >
> > > The reason we had remote modules was the fact that these modules are
> > > too large to be included in the Chromium bundle. In the last months,
> > > we have made numerous remote modules bundled, by applying minifications
> > > and optimizations to each module.
> > >
> > > The remaining remote module that we are currently shipping is LightHouse.
> > > Since the remote appspot server is broken and unlikely to be fixed
> > > anytime soon, now is the best time to finally resolve the remote
> > > modules question.
> > >
> > > Therefore, we remove support for remote modules from the `module.json`
> > > files and `Runtime.js`. Additionally, we update the build system
> > > to properly generate the required files and load them via ES modules.
> > >
> > > We will be able to perform subsequent cleanups in the Runtime to remove
> > > more infrastructure related to scripts/remote modules, but given that
> > > this CL is already quite large we are doing that in a follow-up CL.
> > >
> > > Follow-up action items for the LightHouse folks are to further decrease
> > > the bundle size for LightHouse. Since we are now loading it via ES
> > > modules, we can now use ES imports in the `devtools-dt-bundle.js` as
> > > well. This allows us to remove the copy of the SDK files, as well as
> > > make use of proper ES exports, rather than the browserified requires.
> > >
> > > R=aerotwist@chromium.org,yangguo@chromium.org,paulirish@chromium.org
> > >
> > > Fixed: 1128890
> > > Change-Id: Ib4271a8064b18d31b75d9e28dbe5e3cb3c77d7ff
> > > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416511
> > > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> > > Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
> >
> > TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org
> >
> > Change-Id: I9d3da08108a35d7dadeefd526ea9dbd562ad3432
> > No-Presubmit: true
> > No-Tree-Checks: true
> > No-Try: true
> > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416519
> > Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
> > Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
>
> Change-Id: I26bf0565297c8e167039362b30109d7020bbca56
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418431
> Commit-Queue: Paul Lewis <aerotwist@chromium.org>
> Reviewed-by: Paul Lewis <aerotwist@chromium.org>
TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org,alexrudenko@chromium.org
Change-Id: I0ed24d32c9b68bc4cb8026f6fc362540800beeb0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418408
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
This reverts commit d5044ddf05.
Reason for revert: Fixed Chromium debug issue.
Original change's description:
> Revert "Remove support for remote modules"
>
> This reverts commit 419c91eff6.
>
> Reason for revert: Breaks roll https://chromium-review.googlesource.com/c/chromium/src/+/2416805
>
> Original change's description:
> > Remove support for remote modules
> >
> > LightHouse is currently broken in Canary, because of problems with
> > the appspot server. This isn't the first occurrence of this problem
> > and it becomes increasingly more difficult to figure out why the
> > server keeps on breaking. This is combined with a large infrastructure
> > cost of supporting remote modules and a confusing debugging experience
> > when working with it locally.
> >
> > The reason we had remote modules was the fact that these modules are
> > too large to be included in the Chromium bundle. In the last months,
> > we have made numerous remote modules bundled, by applying minifications
> > and optimizations to each module.
> >
> > The remaining remote module that we are currently shipping is LightHouse.
> > Since the remote appspot server is broken and unlikely to be fixed
> > anytime soon, now is the best time to finally resolve the remote
> > modules question.
> >
> > Therefore, we remove support for remote modules from the `module.json`
> > files and `Runtime.js`. Additionally, we update the build system
> > to properly generate the required files and load them via ES modules.
> >
> > We will be able to perform subsequent cleanups in the Runtime to remove
> > more infrastructure related to scripts/remote modules, but given that
> > this CL is already quite large we are doing that in a follow-up CL.
> >
> > Follow-up action items for the LightHouse folks are to further decrease
> > the bundle size for LightHouse. Since we are now loading it via ES
> > modules, we can now use ES imports in the `devtools-dt-bundle.js` as
> > well. This allows us to remove the copy of the SDK files, as well as
> > make use of proper ES exports, rather than the browserified requires.
> >
> > R=aerotwist@chromium.org,yangguo@chromium.org,paulirish@chromium.org
> >
> > Fixed: 1128890
> > Change-Id: Ib4271a8064b18d31b75d9e28dbe5e3cb3c77d7ff
> > Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416511
> > Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> > Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
>
> TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org
>
> Change-Id: I9d3da08108a35d7dadeefd526ea9dbd562ad3432
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416519
> Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
> Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
Change-Id: I26bf0565297c8e167039362b30109d7020bbca56
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2418431
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This reverts commit 419c91eff6.
Reason for revert: Breaks roll https://chromium-review.googlesource.com/c/chromium/src/+/2416805
Original change's description:
> Remove support for remote modules
>
> LightHouse is currently broken in Canary, because of problems with
> the appspot server. This isn't the first occurrence of this problem
> and it becomes increasingly more difficult to figure out why the
> server keeps on breaking. This is combined with a large infrastructure
> cost of supporting remote modules and a confusing debugging experience
> when working with it locally.
>
> The reason we had remote modules was the fact that these modules are
> too large to be included in the Chromium bundle. In the last months,
> we have made numerous remote modules bundled, by applying minifications
> and optimizations to each module.
>
> The remaining remote module that we are currently shipping is LightHouse.
> Since the remote appspot server is broken and unlikely to be fixed
> anytime soon, now is the best time to finally resolve the remote
> modules question.
>
> Therefore, we remove support for remote modules from the `module.json`
> files and `Runtime.js`. Additionally, we update the build system
> to properly generate the required files and load them via ES modules.
>
> We will be able to perform subsequent cleanups in the Runtime to remove
> more infrastructure related to scripts/remote modules, but given that
> this CL is already quite large we are doing that in a follow-up CL.
>
> Follow-up action items for the LightHouse folks are to further decrease
> the bundle size for LightHouse. Since we are now loading it via ES
> modules, we can now use ES imports in the `devtools-dt-bundle.js` as
> well. This allows us to remove the copy of the SDK files, as well as
> make use of proper ES exports, rather than the browserified requires.
>
> R=aerotwist@chromium.org,yangguo@chromium.org,paulirish@chromium.org
>
> Fixed: 1128890
> Change-Id: Ib4271a8064b18d31b75d9e28dbe5e3cb3c77d7ff
> Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416511
> Reviewed-by: Paul Lewis <aerotwist@chromium.org>
> Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
TBR=yangguo@chromium.org,paulirish@chromium.org,aerotwist@chromium.org,tvanderlippe@chromium.org
Change-Id: I9d3da08108a35d7dadeefd526ea9dbd562ad3432
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416519
Reviewed-by: Alex Rudenko <alexrudenko@chromium.org>
Commit-Queue: Alex Rudenko <alexrudenko@chromium.org>
LightHouse is currently broken in Canary, because of problems with
the appspot server. This isn't the first occurrence of this problem
and it becomes increasingly more difficult to figure out why the
server keeps on breaking. This is combined with a large infrastructure
cost of supporting remote modules and a confusing debugging experience
when working with it locally.
The reason we had remote modules was the fact that these modules are
too large to be included in the Chromium bundle. In the last months,
we have made numerous remote modules bundled, by applying minifications
and optimizations to each module.
The remaining remote module that we are currently shipping is LightHouse.
Since the remote appspot server is broken and unlikely to be fixed
anytime soon, now is the best time to finally resolve the remote
modules question.
Therefore, we remove support for remote modules from the `module.json`
files and `Runtime.js`. Additionally, we update the build system
to properly generate the required files and load them via ES modules.
We will be able to perform subsequent cleanups in the Runtime to remove
more infrastructure related to scripts/remote modules, but given that
this CL is already quite large we are doing that in a follow-up CL.
Follow-up action items for the LightHouse folks are to further decrease
the bundle size for LightHouse. Since we are now loading it via ES
modules, we can now use ES imports in the `devtools-dt-bundle.js` as
well. This allows us to remove the copy of the SDK files, as well as
make use of proper ES exports, rather than the browserified requires.
R=aerotwist@chromium.org,yangguo@chromium.org,paulirish@chromium.org
Fixed: 1128890
Change-Id: Ib4271a8064b18d31b75d9e28dbe5e3cb3c77d7ff
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2416511
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
In Devtools-Frontend we load images without a leading slash, e.g.
url(Images/checker.png). This works within devtools, but breaks this
component server as the path ends up as
/component_docs/my_component/Image/checker.png. So we check if the path
ends in Images/*.* and if so, remove anything before it. Then it will be
resolved correctly.
Fixed: 1128914
Change-Id: I476165d16b19713b3c095d5969fac95a5d26a678
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2414190
Reviewed-by: Kateryna Prokopenko <kprokopenko@google.com>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
This refactors away the cachedResources from an object map
to a normal Map as defined in `Runtime.js`. The Map is used during
boot time by setting the relevant stylesheet contents, which is
included by `build_release_applications`. Moreover, it moves the
`*_module.js` files into the `modules` array rather than scripts.
This ensures that `*_module.js` files can use ES imports.
In a follow-up CL, we can do additional cleanup in the Runtime
to stop retrieving `resources` in `_loadResources`, as that should
no longer be possible. (In both debug and non-debug we build the
appropriate `_module.js` files)
R=aerotwist@chromium.org,aerotwist@chromium.org
Bug: 1058320
Change-Id: I89602b332360338f5914038f6cd505f75b531f8e
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2398829
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
While we implemented this check for `devtools_module` and
`devtools_entrypoint`, we did not do so for `devtools_pre_built`.
This caused build failures yesterday when we forgot to add the
live directive of lit-html in the GRD files.
Therefore, implement the same check for `devtools_pre_built`. This
not only catches the live directive file missing, but also found out
that the imports for Acorn were using the wrong version. We use the
`.mjs` bundles from Acorn, not the `.js` versions.
R=jacktfranklin@chromium.org,aerotwist@chromium.org
Bug: 1126630
Change-Id: I54004efda6fb0ac50f894262f09fe2104d1b2f86
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2403322
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Checking the shape of localization API calls:
if the node is Common.i18n.getLocalizedString,
1. There should be at least two arguments
2. The first argument should be the string instance function 'str_',
3. The second argument should reference the UIStrings object like 'UIStrings.url'
The code would look like:
i18n.i18n.getLocalizedString(str_, UIStrings.url);
Bug: 941561
Change-Id: I1336867b06dd727f5164e6b1d7ac7ae6ed6ea446
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2245769
Commit-Queue: Christy Chen <chrche@microsoft.com>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Vidal Diazleal <vidorteg@microsoft.com>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
This check will detect (and autofix) any string resources that are not used in the code anymore. If a developer deletes a localization call but forgets to delete it from the UIStrings structure, the check will warn/remove it.
Testing steps
1. Add the following to the CoverageView.js right after import statements
export const UIStrings = {
/**
*@description Text in Coverage List View of the Coverage tab
*/
perFunction: 'Per function',
/**
*@description Text in Coverage List View of the Coverage tab
*/
perBlock: 'Per block',
};
2. Change:
label: ls`Per function`,
To the Loc V2 API call:
label: i18n.i18n.getLocalizedString(str_, UIStrings.perFunction),
3. Change:
label: ls`Per block`,
To not use any localization API
label: "Per block",
4. Run
node check_localizable_resources.js --autofix
The Loc V1 check would remove the two entries from grdp
The Loc V2 check would remove perBlock entry from UIStrings
See Loc design doc #Presubmit section for details
https://docs.google.com/document/d/1L6TkT2-42MMQ72ZSBMFwUaq7M6mDgA2X0x8oHHKaV_U/edit#heading=h.w1no7qaa0mi0
Bug: 941561
Change-Id: Ic5f3ee6e9c1586bb3226593c32bc7af7e49a547a
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2236544
Commit-Queue: Christy Chen <chrche@microsoft.com>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
This CL adds Puppeteer as frontend dependency. There are no call sites
that use this, and in this first CL only the Puppeteer Connection class
is exposed for use. As Puppeteer is agnostified to its environment, more
of it can be made available for use within the DevTools frontend
codebase.
Bug: 1107392
Change-Id: Ie29907af389eddb2e3a7bd260b64237529a9aeba
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2354098
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Tim van der Lippe