Repository navigation
Conversation
|
@ayazhafiz do you mind if i take this on so that we can get this merged before the release tomorrow? |
|
Of course
…On Tue, Feb 2, 2021 at 4:17 PM Keen Yee Liau ***@***.***> wrote:
@ayazhafiz <https://github.com/ayazhafiz> do you mind if i take this on
so that we can get this merged before the release tomorrow?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#40621 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE6GL6U6NMOVUJI77IA3WNLS5B2WPANCNFSM4WXXCD4Q>
.
|
cd44fc8 to
81c1fd1
Compare
Two motivations behind this change: 1. We would like to expose the types of the Language Service to external users (like the VSCode extension) via the npm package, on the top level of the package 2. We would like the View Engine and Ivy LS to share a common interface (notably after the inclusion of `getTcb`, the Ivy LS upholds a strict superset of `ts.LanguageService`; previously both VE and Ivy LS were aligned on `ts.LanguageService`.) To this end, this commit refactors the exports on the toplevel of the `language-service/` package to just be types common to both the VE and Ivy language services. The VE and Ivy build targets then import and use these types accordingly, and the expectation is that an external user will just import the relevant typings from the toplevel package without diving into either the VE or Ivy sources. Follow up on angular#40607
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
FYI, there was a lint failure due to the It turns out the problem was that For reference, the error message from {
"success": false,
"files": [
{
"filename": "packages/language-service/BUILD.bazel",
"formatted": true,
"valid": true,
"warnings": [
{
"start": {
"line": 19,
"column": 13
},
"end": {
"line": 19,
"column": 23
},
"category": "constant-glob",
"actionable": true,
"message": "Glob pattern \"index.ts\" has no wildcard ('*'). Constant patterns can be error-prone, move the file outside the glob.",
"url": "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/bazelbuild/buildtools/blob/master/WARNINGS.md#constant-glob"
}
]
}
]
}UPDATE: I have created angular/dev-infra#2346 to track the issue. |
gkalpak
left a comment
There was a problem hiding this comment.
LGTM for dev-infra.
Reviewed-for: dev-infra
…ngular#40621) This is patch PR for angular#40621. Two motivations behind this change: 1. We would like to expose the types of the Language Service to external users (like the VSCode extension) via the npm package, on the top level of the package 2. We would like the View Engine and Ivy LS to share a common interface (notably after the inclusion of `getTcb`, the Ivy LS upholds a strict superset of `ts.LanguageService`; previously both VE and Ivy LS were aligned on `ts.LanguageService`.) To this end, this commit refactors the exports on the toplevel of the `language-service/` package to just be types common to both the VE and Ivy language services. The VE and Ivy build targets then import and use these types accordingly, and the expectation is that an external user will just import the relevant typings from the toplevel package without diving into either the VE or Ivy sources. Follow up on angular#40607 PR Close angular#40621
…40621) (#40695) This is patch PR for #40621. Two motivations behind this change: 1. We would like to expose the types of the Language Service to external users (like the VSCode extension) via the npm package, on the top level of the package 2. We would like the View Engine and Ivy LS to share a common interface (notably after the inclusion of `getTcb`, the Ivy LS upholds a strict superset of `ts.LanguageService`; previously both VE and Ivy LS were aligned on `ts.LanguageService`.) To this end, this commit refactors the exports on the toplevel of the `language-service/` package to just be types common to both the VE and Ivy language services. The VE and Ivy build targets then import and use these types accordingly, and the expectation is that an external user will just import the relevant typings from the toplevel package without diving into either the VE or Ivy sources. Follow up on #40607 PR Close #40621 PR Close #40695
This is patch PR for angular#40621. Two motivations behind this change: 1. We would like to expose the types of the Language Service to external users (like the VSCode extension) via the npm package, on the top level of the package 2. We would like the View Engine and Ivy LS to share a common interface (notably after the inclusion of `getTcb`, the Ivy LS upholds a strict superset of `ts.LanguageService`; previously both VE and Ivy LS were aligned on `ts.LanguageService`.) To this end, this commit refactors the exports on the toplevel of the `language-service/` package to just be types common to both the VE and Ivy language services. The VE and Ivy build targets then import and use these types accordingly, and the expectation is that an external user will just import the relevant typings from the toplevel package without diving into either the VE or Ivy sources. Follow up on angular#40607
…40773) This is patch PR for #40621. Two motivations behind this change: 1. We would like to expose the types of the Language Service to external users (like the VSCode extension) via the npm package, on the top level of the package 2. We would like the View Engine and Ivy LS to share a common interface (notably after the inclusion of `getTcb`, the Ivy LS upholds a strict superset of `ts.LanguageService`; previously both VE and Ivy LS were aligned on `ts.LanguageService`.) To this end, this commit refactors the exports on the toplevel of the `language-service/` package to just be types common to both the VE and Ivy language services. The VE and Ivy build targets then import and use these types accordingly, and the expectation is that an external user will just import the relevant typings from the toplevel package without diving into either the VE or Ivy sources. Follow up on #40607 PR Close #40773
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Two motivations behind this change:
users (like the VSCode extension) via the npm package, on the top
level of the package
(notably after the inclusion of
getTcb, the Ivy LS upholds astrict superset of
ts.LanguageService; previously both VE and IvyLS were aligned on
ts.LanguageService.)To this end, this commit refactors the exports on the toplevel of the
language-service/package to just be types common to both the VE andIvy language services. The VE and Ivy build targets then import and use
these types accordingly, and the expectation is that an external user
will just import the relevant typings from the toplevel package without
diving into either the VE or Ivy sources.
Follow up on #40607
Does this PR introduce a breaking change?
Yes, the public API has changed. However I am not aware of any package using
@angular/language-servicefor its surface APIs other than the VSCode extension, for which this change is motivated by.