Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(language-service): use single entry point for Ivy and View Engine #40967

Closed
wants to merge 1 commit into from

Conversation

kyliau
Copy link
Contributor

@kyliau kyliau commented Feb 23, 2021

Currently there are two entry points for the @angular/language-service
package:

  • @angular/language-service
    This default entry point is for View Engine LS. Through the redirection
    of main field in package.json, it resolves to
    ./bundles/language-service.js.
  • @angular/language-service/bundles/ivy.js
    This secondary entry point is for Ivy LS.

TypeScript recently changed the behavior of tsserver to allow only package
names as plugin names 1 for security reasons. This means the secondary
entry point for Ivy LS can no longer be used.
We implemented a quick hack in the module resolver (in the extension repo)
to fix this, but the long term fix should be in @angular/language-service.

Here, the main field in package.json is changed to index.js, and in the
index file we conditionally load View Engine or Ivy based on the input config.
This eliminates the need for multiple entry points.

As part of this PR, I also removed all source code for View Engine and Ivy
included in the NPM package. Consumers of this package should run the bundled
output and nothing else. This would help us prevent an accidental import that
results in execution of unbundled code.

The new layout of the NPM package is as follows:

@angular/language-service
├── api.d.ts
├── api.js
├── bundles
│   ├── ivy.js
│   └── language-service.js
├── index.d.ts
├── index.js
└── package.json

cc: @ivanwonder

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • angular.io application / infrastructure changes
  • Other... Please describe:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

@kyliau kyliau added area: language-service Issues related to Angular's VS Code language service target: major This PR is targeted for the next major release labels Feb 23, 2021
@kyliau kyliau requested a review from atscott February 23, 2021 19:16
@ngbot ngbot bot added this to the Backlog milestone Feb 23, 2021
@google-cla google-cla bot added the cla: yes label Feb 23, 2021
@pullapprove pullapprove bot requested a review from gkalpak February 23, 2021 19:16
Comment on lines 21 to 25
return plugin?.getExternalFiles?.(proj) || [];
}

export function onConfigurationChanged(config: any): void {
plugin?.onConfigurationChanged?.(config);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this is a little bit awkward given that you have to call create first but I can't think of a better way...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whether we can assert the plugin has been created by tsserver. If not, the tsserver cannot invoke the function.

https://github.com/microsoft/TypeScript/blob/5280ba400c071c87e6ba25c7d8d1ac9c304fe2d4/src/server/project.ts#L1645-L1651

packages/language-service/index.ts Outdated Show resolved Hide resolved
packages/language-service/index.ts Outdated Show resolved Hide resolved
@atscott
Copy link
Contributor

atscott commented Feb 23, 2021

Quick question @kyliau - would this be considered a breaking change since it changes the "main" property in package.json? Or is there another reason this targets major only?

@kyliau kyliau force-pushed the single-entry-point branch 2 times, most recently from fd23451 to e595b8d Compare February 24, 2021 00:03
@ivanwonder
Copy link
Contributor

entry_point = "//packages/language-service:index.ts",

@kyliau the entry_point is wrong for ve bundles.

Copy link
Member

@gkalpak gkalpak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍
(Just a couple of question - out of curiosity mostly 🧐)

Reviewed-for: dev-infra

packages/language-service/index.ts Outdated Show resolved Hide resolved
packages/language-service/BUILD.bazel Show resolved Hide resolved
Currently there are two entry points for the `@angular/language-service`
package:

- `@angular/language-service`
  This default entry point is for View Engine LS. Through the redirection
  of `main` field in `package.json`, it resolves to
  `./bundles/language-service.js`.
- `@angular/language-service/bundles/ivy.js`
  This secondary entry point is for Ivy LS.

TypeScript recently changed the behavior of tsserver to allow only package
names as plugin names [1] for security reasons. This means the secondary
entry point for Ivy LS can no longer be used.
We implemented a quick hack in the module resolver (in the extension repo)
to fix this, but the long term fix should be in `@angular/language-service`.

Here, the `main` field in `package.json` is changed to `index.js`, and in the
index file we conditionally load View Engine or Ivy based on the input config.
This eliminates the need for multiple entry points.

As part of this PR, I also removed all source code for View Engine and Ivy
included in the NPM package. Consumers of this package should run the bundled
output and nothing else. This would help us prevent an accidental import that
results in execution of unbundled code.

[1]: microsoft/TypeScript#42713
@kyliau
Copy link
Contributor Author

kyliau commented Feb 24, 2021

Quick question @kyliau - would this be considered a breaking change since it changes the "main" property in package.json? Or is there another reason this targets major only?

@atscott It's technically not a breaking change since @angular/language-service is considered a "private" package, much like @angular/compiler-cli. But since I'm making drastic changes to the package contents (removed all source files), I don't feel comfortable doing it in a patch release.

@kyliau kyliau added the action: merge The PR is ready for merge by the caretaker label Feb 24, 2021
@kyliau
Copy link
Contributor Author

kyliau commented Feb 24, 2021

entry_point = "//packages/language-service:index.ts",

@kyliau the entry_point is wrong for ve bundles.

@ivanwonder Thanks for pointing that out, I've fixed the entry point :)

This was referenced Mar 15, 2021
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Mar 27, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker area: language-service Issues related to Angular's VS Code language service cla: yes target: major This PR is targeted for the next major release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants