I propose creating an adapter assembly in dotnet/roslyn for each assembly (or project) that currently has IVT access to Roslyn but does not live in this repository.
- IVTs from Roslyn layers to the adapter assemblies would be allowed
- IVTs from Roslyn layers to assemblies outside of dotnet/roslyn would not be allowed
IVTs from the adapter assemblies to assemblies outside of dotnet/roslyn would not be allowed This rule was eliminated in order to prevent unknown other components from treating the adapter interfaces as public APIs.
This proposal maximizes the ability of developers working in dotnet/roslyn to make changes to non-public APIs without breaking downstream code. In cases where an internal API is used by a product primarily used outside of dotnet/roslyn (e.g. TypeScript), the change to the internal API can be accompanied in the same pull request by a corresponding change to the adapter assembly. From the perspective of the outside product, these changes would be non-breaking.
This proposal also avoids the requirement that external projects create or use an analyzer to avoid breaking changes due to IVTs.
The primary drawback of this proposal is some code duplication may occur in the adapter assemblies. However, this duplication serves a specific and valuable purpose: it isolates downstream code from refactoring operations performed in Roslyn.
I propose creating an adapter assembly in dotnet/roslyn for each assembly (or project) that currently has IVT access to Roslyn but does not live in this repository.
IVTs from the adapter assemblies to assemblies outside of dotnet/roslyn would not be allowedThis rule was eliminated in order to prevent unknown other components from treating the adapter interfaces as public APIs.This proposal maximizes the ability of developers working in dotnet/roslyn to make changes to non-public APIs without breaking downstream code. In cases where an internal API is used by a product primarily used outside of dotnet/roslyn (e.g. TypeScript), the change to the internal API can be accompanied in the same pull request by a corresponding change to the adapter assembly. From the perspective of the outside product, these changes would be non-breaking.
This proposal also avoids the requirement that external projects create or use an analyzer to avoid breaking changes due to IVTs.
The primary drawback of this proposal is some code duplication may occur in the adapter assemblies. However, this duplication serves a specific and valuable purpose: it isolates downstream code from refactoring operations performed in Roslyn.