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

amd-dependency path not resolving when... #7756

Closed
kabua opened this issue Mar 31, 2016 · 8 comments
Closed

amd-dependency path not resolving when... #7756

kabua opened this issue Mar 31, 2016 · 8 comments
Labels
Needs More Info The issue still hasn't been fully clarified

Comments

@kabua
Copy link

kabua commented Mar 31, 2016

TypeScript Version:
1.8.6.0

Module System
AMD

Background
We have a common project (let's call it WebUtils) located at c:\repos\WebUtils. And a ts file located at c:\repos\WebUtils\Libs\A\B\C\Person.ts. And Person.ts requires a legacy file called Company.js which is located at c:\repos\WebUtils\Libs\A\B\D\Company.js.

Therefore, within Person.ts is a amd-dependency directive like so:

/// <amd-dependency path="./D/Company" name="Company" />

When we compile the WebUtils project everything builds just fine.

Next, in our application (let's say it is located at c:\repos\App1) we have another ts file which is located at c:\repos\App1\Spa\main.ts which 'requires' the Person.ts file from WebUtils.

After trying several approaches and reading several issues (like: #2338, and #293 to name a few) it appears that the correct way to reference Person.ts would be like this:

import Person = require("../../../WebUtils/Libs/A/B/C/Person");

Which resolves just fine. However, when we build App1 the compiler tries to compile Person.ts it can't find Company.

Expected behavior:
To be able to resolve the amd-dependency directive relative path of ".\D\Company" based upon the current file's location that is being compiled.

Actual behavior:
Either a) the amd-dependency is being ignored or b) The relative path is not being honored correctly.

Notes:

  1. Both projects are using "AMD" Module systems.
  2. Both projects are within a Visual Studio 2015 Update 1 solution.
@DanielRosenwasser
Copy link
Member

So Person.ts is located at

  • c:\repos\WebUtils\Libs\A\B\C\Person.ts

And Company.js is located at

  • c:\repos\WebUtils\Libs\A\B\D\Company.js

So each file's parent is a sibling of the other. Wouldn't you want ../D/Company? So

/// <amd-dependency path="./D/Company" name="Company" />

@kabua
Copy link
Author

kabua commented Apr 1, 2016

Ah yes, thanks. In this example (due to a typo) that would be correct.

In our 'real' code, it looks something like: c:\repos\WebUtils\Libs\A\B\C\D\Company.js (a child folder of C) but that really doesn't matter. The point is; the relative path resolver work correctly if we build from WebUtils but something is gets confused if the code gets built starting from the App1 location. Company.js is still the same relative location from Person.js, regardless of how the compiler got to Person.js.

@mhegazy
Copy link
Contributor

mhegazy commented Apr 21, 2016

do you use --outDir or --out? do you specify a --rootDir? can you provide a repro we can look at?

@mhegazy mhegazy added the Needs More Info The issue still hasn't been fully clarified label Apr 21, 2016
@kabua
Copy link
Author

kabua commented Apr 28, 2016

No, I didn't use --outDir or --out or --rootDir. Sure, I can provide a simple VS 2015 example but not today, perhaps this weekend.

@mhegazy
Copy link
Contributor

mhegazy commented May 20, 2016

@kabua is this still an issue? can you share the project?

@kabua
Copy link
Author

kabua commented Jun 1, 2016

I would love too but I have a very tight deal-line and then I'm on vacation, I'll be back the last week of June, at which point I can create something for you. thanks.

@mhegazy
Copy link
Contributor

mhegazy commented Sep 21, 2016

any news?

@kabua
Copy link
Author

kabua commented Sep 28, 2016

I just found out yesterday that 2.0 has finally been released. As soon as I can wrap up several items in my plate, I plan on revisiting this issue.

@mhegazy mhegazy closed this as completed Dec 29, 2016
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Needs More Info The issue still hasn't been fully clarified
Projects
None yet
Development

No branches or pull requests

3 participants