Google Git
Sign in
chromium / devtools / devtools-frontend / 3b1f7453a734a68f8e2532c2027b46aaacaed386
commit3b1f7453a734a68f8e2532c2027b46aaacaed386[log] [tgz]
authorTim van der Lippe <[email protected]>Fri Jan 08 11:25:13 2021
committerCommit Bot <[email protected]>Fri Jan 08 12:39:52 2021
tree4f92d9ac973e4c94a68f984bf26b5c7f482150cb
parent31082e637b9550fe1da8dea093a37bd76d533253 [diff]
Make UIString and i18n return tagged localized strings

The LocalizedString type alias in UIString.js is a so-called
"branded type". A branded type alias allows us to construct
special types in type-casts and enforce that these specific
alias are used. The following properties hold:

1. A string can be force-casted into a LocalizedString
2. A LocalizedString can be enforced as argument type
3. A LocalizedString can be downcasted/used as regular string
4. A LocalizedString can normally not be concatenated, unless
force-casts are added (which is strongly discouraged, since
localization can be structure-dependent)

These properties are for example used to enforce that all titles
of the ViewRegistration declarations are localized strings. I have
manually verified that passing in a regular string will correctly
cause TypeScript to error.

The new i18n localization system uses the same force-cast to make
sure that the new localized strings also adhere to the same
structure.

As a result of this change, I discovered several inconsistencies
in how types were used. For example, strings were being passed
in and assumed to be localized, but not enforced. Therefore,
this CL contains several cleanups that require the LocalizedString
itself and hence have to be bundled in this CL.

[email protected]

Change-Id: I2faffde47069c900e2e5e7c0ebb460d0792d2935
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2612861
Reviewed-by: Peter Marshall <[email protected]>
Commit-Queue: Tim van der Lippe <[email protected]>
24 files changed
tree: 4f92d9ac973e4c94a68f984bf26b5c7f482150cb
  1. build_overrides/
  2. docs/
  3. front_end/
  4. inspector_overlay/
  5. node_modules/
  6. scripts/
  7. test/
  8. third_party/
  9. v8/
  10. .clang-format
  11. .editorconfig
  12. .eslintignore
  13. .eslintrc.js
  14. .gitattributes
  15. .gitignore
  16. .gn
  17. .npmignore
  18. .npmrc
  19. .style.yapf
  20. .stylelintignore
  21. .stylelintrc.json
  22. all_devtools_files.gni
  23. all_devtools_modules.gni
  24. AUTHORS
  25. BUILD.gn
  26. COMMON_OWNERS
  27. DEPS
  28. devtools_grd_files.gni
  29. devtools_image_files.gni
  30. devtools_module_entrypoints.gni
  31. ENG_REVIEW_OWNERS
  32. INFRA_OWNERS
  33. LICENSE
  34. LIGHTHOUSE_OWNERS
  35. OWNERS
  36. package-lock.json
  37. package.json
  38. PRESUBMIT.py
  39. README.md
  40. tsconfig.base.json
  41. tsconfig.json
  42. WATCHLISTS
README.md

Chrome DevTools frontend

npm package

The client-side of the Chrome DevTools, including all JS & CSS to run the DevTools webapp.

Source code

The frontend is available on chromium.googlesource.com.

Design guidelines

Please be aware that DevTools follows additional development guidelines.

Issue triage

The issue triage guidelines can be found here.

Workflows

Instructions to set up, use, and maintain a DevTools frontend checkout can be found here.

Additional references

Source mirrors

DevTools frontend repository is mirrored on GitHub.

DevTools frontend is also available on NPM as the chrome-devtools-frontend package. It's not currently available via CJS or ES modules, so consuming this package in other tools may require some effort.

The version number of the npm package (e.g. 1.0.373466) refers to the Chromium commit position of latest frontend git commit. It's incremented with every Chromium commit, however the package is updated roughly daily.

Getting in touch