Index.html is produced locally when outputPath is a remote folder

[joshorvis]

UPDATE 2020-12-20: I discovered this morning that the index.html files ARE being produced, but they are being pushed to my local machine instead of the remove machine.

From my angular.json: "outputPath": "\\\\remote-computer-name\\all-projects-folder\\project-folder"

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

🐞 Bug report

Command (mark with an x)

• [ ] new
• [x] build
• [ ] serve
• [ ] test
• [ ] e2e
• [ ] generate
• [ ] add
• [ ] update
• [ ] lint
• [ ] extract-i18n
• [ ] run
• [ ] config
• [ ] help
• [ ] version
• [ ] doc

Is this a regression?

No. Discovered in 9.1.7. Updated to latest hoping to fix the problem. Still exists.

Description

Title says it all. When run ng build, everything works as expected. When I run ng build --configuration=remote-build, the build completes without errors and all files are pushed to the remote folder EXCEPT index.html.

🔬 Minimal Reproduction

Link to repro project here: https://github.com/joshorvis/remote-build. (Only change from the default ng new is a new target added in angular.json)

1. set up a folder you can access on another machine. confirm file permissions aren't blocking writes from your local machine.
2. npm install project on local machine. Update angular.json line 86 with the network path to your remote folder.
3. run ng build. See index.html in local project folder /dist/remote-build
4. run ng build --configuration=remote-build. See everything but index.html
5. cry with me.

UPDATE: It appears that mapping the remote folder to a network drive letter will produce the index.html as expected.

[dgp1130]

Had some discussion on this today and identified two questions brought up here:

1. Should we allow users to output to a path outside the project directory?
2. 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.

[joshorvis]

I'm a bit surprised only index.html is having problems here. That's the part that's got me scratching my head... I would expect it to be an all-or-none scenario but admittedly I've never looked under the hood so I have no idea what I'm talking about.

FWIW, my use case is that I am a solo dev; I've got an older machine that has the "old school" server setup (IIS, MSSQL, etc) and a newer machine that I want to use as my primary machine. I'm mostly doing serverless stuff these days, so I don't want to install all that old crap on the new machine just to work on older projects. Here I'm trying to output my build straight to the old machine with --watch so that I can use it as a dev preview server.

So for me, mapping to a network drive and moving on with life is no sweat (except for the sleep lost wondering WHYYYYY).

For others, personally I think perhaps an error that you could disable in angular.json may be more appropriate as it creates a whole unexpected folder tree stemming from the root on your local machine. And I think calling out the workaround in the message is a great idea.

[juaasca]

There is some action planned? I have the same issue.

The workarround of mapping it to local directory is ok if you work alone. If you have other team mates, is mandatory all of them have the same map. Moreover, if your computer is changed, we have in mind that mapping the same local path of previous pc or change code everytime it happens.