microsoft / microsoft/TypeScript

Add the Node that comes with Visual Studio as a NodePath fallback in the .targets file in the Microsoft.TypeScript.MSBuild Nuget package

Aperta
#38,247 3 commenti 1 reazione 2 assegnatari Vedi su GitHub

@HannahOshlag ci sta già lavorando.

Dal 2/9/2022.

Suggestion Visual Studio
Lingua principale
Go
Stelle
111k
Fork
14.3k
Merge medio
1g 19h
PR unite (30g)
117

Descrizione

I am working on a new project using ASPNET Core 3.1 and I wanted to write our font-end code in TypeScript, but found a little problem: You can't use TypeScript and build the project using the dotnet CLI commands if you don't have a stand alone installation of Node. If you build using Visual Studio, it works ok because VS now comes with Node, but building in Azure Pipelines or local with the "dotnet build" command results in an error saying Node could not be found.

My project is referencing the Microsoft.TypeScript.MSBuild nuget package.

On March 20th 2020, I created a simple repro at https://github.com/kelps/TypeScriptBuildRepro and also submitted a VS feedback about this at https://developercommunity.visualstudio.com/content/problem/957892/typescript-files-do-not-build-using-dotnet-cli-com.html.

@timheuer helped me diagnose it and the problem was that Node needed to be in the Path to work. I didn't like that because Visual Studio already comes with Node and I shouldn't need to have another separate Node install to run this. @madskristensen's BuildWebCompiler Nuget package also uses Node to compile .less/.sass/... files and it just works, without a stand alone Node install.

After a long time testing and researching I was able to create a very simple work around. I added a msbuild Task to my .csproj file that runs before the TypeScript compilation and sets the NodePath to the one that comes with VS if it is still empty. When it worked, I removed that code from my .csproj file and placed it in the Directory.Build.targets file in the solution directory.

My suggestion is to add some form of that code to the .targets file in the Microsoft.TypeScript.MSBuild Nuget package.

The master in my repo now has the code that works. To see the build failling, just rename the Directory.Build.targets file and try to build the solution with "dotnet build" in a computer without a stand alone Node installation (or at least without Node in the %path%).

It is a simple "fix" that provides a good fallback for TypeScript compilation with ASPNET Core on Windows. I am sure my code can be improved, but it is a good start. It uses vswhere to find the VS Node path.

For reference, here is the code in my .targets file.

<Project ToolsVersion="15.0">
  <!--https://stackoverflow.com/questions/31664834/customize-system-environment-variable-path-for-msbuild-exec-task#31670922-->
  <!--http://blog.jdhardy.ca/2011/12/setting-environment-variables-for.html-->
  <!--bat script for findind the Visual Studio instalation path for Node and setting it in the appropriate variable before building TypeScript files-->
  <PropertyGroup>
    <SetNodePath>
    <![CDATA[
	@setlocal enabledelayedexpansion
	@for /f "usebackq tokens=*" %%i in (`"%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere" -latest -find **\node.exe`) do (@set nodePath=%%~dpi)
	@echo %NodePath%
    ]]></SetNodePath>
  </PropertyGroup>

  <!--Target that runs the script above if the node path isn't set yet and it is running on Windows-->
  <Target Name="FindAndSetNodePath" BeforeTargets="PreComputeCompileTypeScriptWithTSConfig" Condition="'$(NodePath)' == '' AND '$(OS)' == 'Windows_NT' AND exists('$(MSBuildProgramFiles32)\Microsoft Visual Studio\Installer\vswhere.exe')">
    <Exec Command="$(SetNodePath)" ConsoleToMSBuild="true">
      <Output TaskParameter="ConsoleOutput" PropertyName="NodePath"/>
    </Exec>
    <Message ContinueOnError="true" Text="NodePath: $(NodePath)" Importance="high" />
  </Target>
</Project>

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Valutazione

Questa issue non è ancora stata valutata.

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.