Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VsTsc does not respect <Link> item metadata for build outputs for UWP #15322

Closed
grork opened this issue Apr 23, 2017 · 8 comments
Closed

VsTsc does not respect <Link> item metadata for build outputs for UWP #15322

grork opened this issue Apr 23, 2017 · 8 comments
Assignees
Labels
Suggestion An idea for TypeScript Visual Studio Integration with Visual Studio

Comments

@grork
Copy link

grork commented Apr 23, 2017

VsTsc does not respect item metadata for build outputs for UWP, and instead placed in the root of the outputted AppX.

TypeScript Version: 2.1.5 / VS2017 15.1.26403.7

Code

<TypeScriptCompile Include="..\..\Foo.ts">
   <Link>MyFolder\foo.ts</Link>
</TypeScriptCompile>

Expected behavior:
When compiled, I expect Foo.ts to be outputted into MyFolder\foo.js.

Actual behavior:
a) It shows up in the solution explorer in the right place (E.g. it's in MyFolder\foo.ts as a project item (good)
b) It compiled (good)
c) when it's deployed in my UWP, it's in the root folder, which means all my paths & references to it now fail to resolve the file.

@minestarks minestarks self-assigned this Apr 27, 2017
@minestarks
Copy link
Member

minestarks commented Apr 27, 2017

This is interesting. My knee jerk reaction is to say it’s by design but don’t want to shoot it down before understanding your goal.

The thing is, we pass all the *.ts files in the project all at once to the tsc.exe, and the compiler doesn’t allow per-file output location.

To implement what you want we’d have to first group files by output location and then invoke multiple calls to the compiler. We're trying to keep things simple in our MSBuild functionality and have it parallel tsconfig.json behavior as much as possible.

Would it be an acceptable compromise to use the --outdir or --outFile option? This will apply to all files in your project. If you want control over individual files' location you can add a post-compile target to your MSBuild file that copies the output (.js) files to the appropriate locations after the compiler is invoked.

@minestarks minestarks added Suggestion An idea for TypeScript Visual Studio Integration with Visual Studio labels Apr 27, 2017
@grork
Copy link
Author

grork commented Apr 28, 2017

Can the --outDir be defined as relative to the MSBuild Output directory? (Or is that it's default?) If so, I can change my app to work with flat output paths. Not great, but consistent & predictable. 🎉

@ifle
Copy link

ifle commented Apr 28, 2017

I have a similar issue.
Suppose we have project WebApp and folder with common files. To the WebApp project we should to add the link to common1.ts file. We added tsconfig file with outdir option, but we must to define the "includes" or "files" option too. This is difficult because there is duplicated settings of included files, both in csproj and tsconfig.

Folder structure:

WebApp
       scripts
              page1.ts
              page2.ts
              common1.ts  - link

Common
       scripts
             common1.ts
             common2.ts

@minestarks
Copy link
Member

@grork

<PropertyGroup>
  <TypeScriptOutDir>foo\bar</TypeScriptOutDir>
</PropertyGroup>

TypeScriptOutDir is the MSBuild property corresponding to the --outDir switch. There's also UI for it (right click on project, Properties, "Redirect JavaScript output to directory")

Note that this doesn't mean you'll necessarily get a flat output structure -- rather the source directory tree will be mirrored under the outdir you specified.

You could reference OutputPath (a common MSBuild property) in the property, but I doubt this is what you want because when the appx is bundled everything's copied to the output directory anyway using the project directory as a base path -- you'd end up with paths like bin\Debug in your appx.

@ifle Sounds like you have a working solution. I think you can leave out the included .ts files from the csproj because you already have them in the tsconfig.json. My suggestions above apply to UWP, if there's something about the WebApp project that makes this impossible you can file a separate issue.

@ifle
Copy link

ifle commented Apr 28, 2017

We can't leave out the included .ts files from the csproj because we need a way to update them in VS

@grork
Copy link
Author

grork commented Apr 29, 2017

I did some digging and while I'm not in a working state, I understand both your comments & why it's behaving the way it is.

tl;dr: tsc.exe wasn't actually compiling the ..\' referenced files at all. If I use rootDirs` in tscconfig.json, it doesn't help.

Some context:

  1. There is a common solution directory
  2. There are two projects -- App & And Tests -- in two child folders of the solution
  3. The code that isn't playing ball is in App\js\foo.ts, and is referenced using ..\App\js\foo.ts path, and <Link />
  4. All the code that is in Tests folder (and project), builds fine, and is dropped in the appropriate structure
  5. Code that is in ..\App\ is flattened in the output
  6. I'm not using module loading or any of that stuff; just referecing them in my html files.

After adjusting my <script /> tags for the flattened structure, my tests started finding the js, and working much better. However some of them still weren't working, and weren't being compiled at all.

Turns out, none of the code in ..\App was being compiled. The reason it was showing up in my test projects outputs was because I had /// <reference path="....." /> at the top of some of my ts files ('cause some times weren't being resolved correclty). It was this that was causing the files to be seen & compiled, and why they're being flattened, rather than reflecting the structure.

I was hoping that through the use of rootDirs in the tscconfig.json, I could actually achive my goal, but it doesn't seem to be respected, or it isn't doing what I think it's doing (I added rootDirs: [ "..\App" ], )

This all used to work in VS2015 + TS 1.8.

I see my paths forward as:

  1. Copy the files into two places, and manually do this when I make changes (bad)
  2. Reference only the outputted JS/.map files from the Tests project. Means I need to build the App project before I run my tests when I'm making changes
  3. Bundle up all the ts into both projects, moving the projects to be in the solution directory
  4. Specify all the files in a files: [] in the tscconfig.json (Which semi-breaks the d.ts-from-winmd tooling). Pain 'cause it basically makes the project pointless.
  5. Throw some side-eye at VS, and just use /// <reference path="..\..\App... /> sections, in the test project/code and adjust my includes
  6. Some how creat a "JavaScript Library" project that I could reference them from?
  7. Poke at it until rootDirs works?

I think for now I'm going to go with 6, since it's the least problematic path. It also leaves the App code itself a more vanilla situation.

@minestarks
Copy link
Member

@grork @ifle sorry for the long delay on this.

I experimented with a bunch of approaches and unfortunately there's no great way of accomplishing what you want. Without some MSBuild hackery, there's no current combination of switches/project properties that will take input files from arbitrary directories and output them in a single directory (or allow fine grained control over where each file is emitted). I will keep looking into what we can add to VS/MSBuild to help.

I do have a recommendation though. Have you considered using --outFile (Msbuild: <TypeScriptOutFile>) to concatenate the output into a single .js file? Then you can include <TypeScriptCompile> inputs from any arbitrary location and the output location will be deterministic (i.e. a single file). I think this could be a really nice solution to your woes.

@minestarks
Copy link
Member

Closing because --outFile is a decent workaround and implementing <Link> as requested isn't plausible for the time being. Thanks for helping me understand your scenario, we'll keep it in mind as we look into improvements the multi-project experience.

@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Suggestion An idea for TypeScript Visual Studio Integration with Visual Studio
Projects
None yet
Development

No branches or pull requests

3 participants