Please reconsider adding support for --poll option for ng build when building libraries

[edumserrano]

Command

build

Description

I'd like you to please reconsider #12487. Please support the --poll option for ng build in libraries.

Describe the solution you'd like

I'd like for the --poll option for ng build to work for libraries as it does for applications.

I stumbled across this issue because I'm running ng build --watch for a library in a Docker container on Windows using WSL2 and the watch mode does not work in my case due to:

In cases where Angular CLI is running in a shared directory on linux VM on a windows host the webpack dev server isn't detecting file changes from the host environment. (ex: Whenever a docker dev environment is running on a windows host.) This is solved by adding poll option to the webpack dev server configuration. By default when no poll interval is set watchpack will use native file system change detection. This change allows for setting the poll interval which will turn on polling. ¹

Note

At least consider adding some note to the ng build docs about this since it took me a while to understand why I kept getting "argument not supported" when using an option that the docs say is available for ng build.

Describe alternatives you've considered

Since the --watch option doesn't work for my case, I've been relying on the use of the --poll option, usually with ng serve. However, now I want to use the --poll with ng build for a library and this doesn't work.

The only workarounds I'm left are:

For some reason nodemon and webpack-dev-server hot reload does not work in WSL2. Downgrading to WSL 1 resolved the issue.

In order for this to work in WSL 2, the project needs to be inside the linux file system. ²

Footnotes

1. feat(webpackDevServer): Add watchOptions for webpackDevServer #1814 ↩

2. Nodemon and webpack-dev-server hot reload not working under WSL 2 after Windows 10 resinstall ↩

[alan-agius4]

Hi @edumserrano, in the first paragraph of the linked documentation it's mentioned that only a subset of options are available when building a library.

When used to build a library, a different builder is invoked, and only the ts-config, configuration, and watch options are applied. All other options apply only to building applications.

We could add the polling option for the library builds although this needs to be provided by ng-packagr, are your files located on the Windows or Linux system?

[edumserrano]

When used to build a library, a different builder is invoked, and only the ts-config, configuration, and watch options are applied. All other options apply only to building applications.

Well that's my bad, I missed that. I focused too much on the table describing the options.

are your files located on the Windows or Linux system?

My files are on Windows and I'm using WLS2.

[alan-agius4]

WSL2 is actually not recommended to be used when having the files on Windows. This is will also hinder the DX as file accesses are particularly slow which causes slow rebuilds.

For the case were files are located on Windows, Microsoft recommends using WSL 1. You can read more about this: https://learn.microsoft.com/en-us/windows/wsl/compare-versions#exceptions-for-using-wsl-1-rather-than-wsl-2

So, while polling might address the problem, it introduces other DX issues. Unless there are compelling reasons beyond this, I'm not too inclined to incorporate it into ng-packagr.

[edumserrano]

That's right @alan-agius4 , and that's why I tried to list the workarounds I know of, one of them being use WSL1.

Do note the start of the link you gave me:

We recommend that you use WSL 2 as it offers faster performance and 100% system call compatibility.

In the future, more and more optimizations will be done to WSL 2 and perhaps they will even figure out a way to eliminate the file performance issue. However, I do think that whether WSL1 supports it or WSL 2 doesn't, is orthogonal to my ask.

As a user, I want to use WSL2, I don't want to have to keep switching from WSL1 to WSL2 from project to project, just because I don't have a poll option when working with Angular libraries.

The fact that there are a couple of workarounds is great, it means developers are not prevented from working and it also reduces the criticality of this issue. However, it would be much nicer for me as a user, to NOT have to keep switching from WSL 2 to WSL 1.

My dev experience so far on Windows with WSL2 has consisted in creating docker named volumes whenever I have a large amount of files I require access on the Docker container, instead of just doing a mount of those files from the Windows filesystem into the Container. This has allowed me to work around slow filesystem performance as described in microsoft/WSL#4197.

And so far I've had no issues with this approach because all the tools I've used allow for some kind of poll option (be it in Angular ecosystem or not). This is why I'd like you to reconsider supporting the --poll option when building libraries.

[edumserrano]

Thank you @alan-agius4 ! 👏

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}