Do we really need NO_TYPEPROVIDERS we don't seem to set it.

[KevinRansom]

[dsyme]

We should keep it, and we should build the compiler with it in some form during CI. My preference is really to build Proto without TP support.

In terms of why

1. I'm pretty certain Fable sets this for their bootstrap of the compiler into the Javascript-hosted compiler. I don't think we should pull the plug on our small part of enabling that.

2. It's also a matter of long-term feature hygiene - TPs are so strongly tied to .NET and quotations that there will always be scope for cuts of F# that don't support them, both now and long term into the future. For example imagine a cut of the F# compiler that compiles to native (in addition to the transpiling cuts in Fable).

cc @alfonsogarciacaro @ncave

[ncave]

It would be helpful to keep those, if that's possible.

Fable currently uses NO_TYPEPROVIDERS for compiling FCS to JavaScript for its REPL, and for fable-compiler-js (which is a F# to JS transpiler running on Node.js/JavaScript without .NET installed).

To @dsyme's point, building FCS using NO_TYPEPROVIDERS with .NET Native AOT works just fine, and it's almost twice as fast (the down side being the large binary). Admittedly, I haven't tried without NO_TYPEPROVIDERS, perhaps that works too.

[dsyme]

@ncave I'm wondering if you would consider submitting an adjustment to our CI in this repo which adds a job compiling FSharp.Compiler.Service.fsproj with NO_TYPEPROVIDERS set?

[ncave]

@dsyme I'm not sure I know enough about the build infrastructure of this repo to properly add this for all platforms, or even if it's needed for all platforms. Perhaps if somebody can help pinpoint the location where this might need to be added. It could be just a separate FCS test build with --define:NO_TYPEPROVIDERS.

[KevinRansom]

Happy to keep it then.