Had some discussion on this today and identified two questions brought up here:
- Should we allow users to output to a path outside the project directory?
- Should we support Windows network paths?
Regarding the first question, from a usability perspective we should avoid putting arbitrary limitations on users. If a solo dev wants to hard code paths on their local machine, that's their prerogative. Enterprises may also have more knowledge about the file systems of its developers and may have some separate scheme. For instance I can imagine a "repos/" folder which contains many repositories (some Angular, some not) but they may want a separate "artifacts/" folder which contains outputs from all repos, similar to bazel-out/ but applied cross-repository. We don't really have any reason to reject such a pattern
It seems like this happens to work already, so there's much we really need to do here. It may be worth adding some tests to verify that the behavior works in CI however so we don't accidentally break it in the future.
Regarding the second question, Windows network paths should probably be supported, although this is tricky because we convert all our paths to the POSIX standard, which looses this kind of information. I'm a bit surprised only index.html is having problems here.
@joshorvis, you mentioned that the index.html page is being generated, but on the wrong computer / wrong path. Can you clarify exactly where the file is being generated vs where you expected it to be? If the file is going to the wrong place then that's a bigger problem than just not getting build outputs. That could unintentionally overwrite some other user data.
Edit: Ah sorry, didn't realize the next part of your comment was also a part of your edit:
Files SHOULD be copying to C:\all-projects-folder\project-folder. on the REMOTE machine. Instead, files are copying to C:\remote-computer-name\all-projects-folder\project-folder on my LOCAL machine
That path mapping makes sense from the POSIX conversion. Potentially other data could be placed there which could get overwritten, aside from just littering the user's computer with random files at weird paths.
Our thought here is that it may be better to warn/error up front when a Windows network path is detected just to preemptively call out its unsupported nature. We don't have tests for this and can't guarantee it will work. Even if it happens to work now for some uses cases (such as those who don't care about the index.html file), we don't want users to start leveraging this "feature" only to be frustrated if it gets broken later.
The workaround of mapping it to a local file directory seems like the best option here (not sure how hard it is to do that). It avoids the POSIX conversion problem and looks just like a regular path to Angular tooling. It's unfortunate that this is necessary, but it does seem like the simplest solution here. The warning/error message could explicitly call this out as a potential workaround.