Disable generation if enabling noEmit flag

[MaryGao]

Our emitter honored --no-emit flag but in the middle of generation, this would lead to some actions taken accidentally like clean up the generation folder etc. It's better to disable generation if enabling noEmit flag at the begining of emitter no matter it is RLC or modular.

This could help fix the files automatical deletion issue in smoke test when typespec code extension enabled.

[qiaozha]

⁠Can we special case the clearSrcFolder only to resolve this ? I feel like no-emit doesn't mean to do nothing.

[MaryGao]

⁠Can we special case the clearSrcFolder only to resolve this ? I feel like no-emit doesn't mean to do nothing.

@qiaozha could you help me understand what is the value we could get from if we don't plan to emit codes?

I learned from emitter template and other emitters e.g csharp that to skip generation at the begining.

Another concern is for performance, during enabling code extension, typespec server side would automatically emit all configed specs with --no-emit flag, since our emitter has performance issue it would occupy the local machine CPU. So personally to make things simpler I prefer to skip at the begining if no much value provided.

[qiaozha]

did you also notice that the above template link is putting no-emit before emitFile? the same for openapi3 emitter https://github.com/microsoft/typespec/blob/main/packages/openapi3/src/openapi.ts#L264.

[MaryGao]

did you also notice that the above template link is putting no-emit before emitFile? the same for openapi3 emitter https://github.com/microsoft/typespec/blob/main/packages/openapi3/src/openapi.ts#L264.

we see both cases, directly returning at the begining like Java or .Net or returning just before the final emitting like openapi. it is more like emitter's owner decision. for long term i agreed that the latter one would be better because we could still verify the emitter's diagnostics even in --no-emit.

but in short term considering we have performance issue, I would prefer to directly return and do that once we fix this issue: #2879.

another thing I was thinking from typespec side it's better to differentiate two cases 1) I don't want to emit files but I want to run emitters to see what happened vs 2) I don't want to emit files & I am not interested in what will happen in that emitter. currently the --no-emit in typespec server would be the second case, because from customers of vs extension may not know emitter output.

[qiaozha]

LGTM, since tcgc doesn't prepare the sdkPackage when it's noEmit, I don't think our own code logic would work as expected with the current implementation either.