Allow only package names as plugin names #42713
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
typescript-bot
added
the
For Milestone Bug
joehillen
reviewed
Feb 9, 2021
kyliau
added a commit
to kyliau/angular
that referenced
this pull request
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. [1]: microsoft/TypeScript#42713
14 tasks
kyliau
added a commit
to kyliau/angular
that referenced
this pull request
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. [1]: microsoft/TypeScript#42713
kyliau
added a commit
to kyliau/angular
that referenced
this pull request
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. [1]: microsoft/TypeScript#42713
kyliau
added a commit
to kyliau/angular
that referenced
this pull request
Feb 24, 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. [1]: microsoft/TypeScript#42713
kyliau
added a commit
to kyliau/angular
that referenced
this pull request
Feb 24, 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. [1]: microsoft/TypeScript#42713
kyliau
added a commit
to kyliau/angular
that referenced
this pull request
Feb 24, 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. [1]: microsoft/TypeScript#42713
zarend
pushed a commit
to angular/angular
that referenced
this pull request
Feb 24, 2021
…#40967) 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 PR Close #40967
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #42712