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

fix(@angular-devkit/build-angular): do not resolve web-workers in server builds #20948

Merged
merged 1 commit into from
May 31, 2021
Merged

fix(@angular-devkit/build-angular): do not resolve web-workers in server builds #20948

merged 1 commit into from
May 31, 2021

Conversation

alan-agius4
Copy link
Collaborator

@alan-agius4 alan-agius4 commented May 26, 2021

Web-workers are not supported on the server and therefore we should not try to request these files from the Angular plugin.
Closes #20877

@alan-agius4 alan-agius4 added the target: patch This PR is targeted for the next patch release label May 26, 2021
@alan-agius4 alan-agius4 requested a review from clydin May 26, 2021 08:10
@google-cla google-cla bot added the cla: yes label May 26, 2021
@clydin
Copy link
Member

clydin commented May 26, 2021

To disable parsing of the new Worker syntax, the server Webpack config partial could be augmented with:

    module: {
      parser: {
        javascript: {
          worker: false,
        }
      }
    },

I think that would essentially mimic the prior v11 behavior.

@alan-agius4
Copy link
Collaborator Author

I should have mentioned why, I did go with this approach instead of disabling the parser. I updated the PR description and commit message to reflect this.

@clydin
Copy link
Member

clydin commented May 27, 2021

Disabling the worker parsing does stop Webpack from treating new Worker(... code as dependencies. But with that disabled, Webpack then sees a new URL(... by itself and decides that is a dependency. So to replicate the v11 behavior:

    module: {
      parser: {
        javascript: {
          worker: false,
          url: false,
        }
      }
    },

This approach also has the advantage of not hard coding file naming conventions which may or may not be used by a project.

Alternatively, this issue could be handled directly in a project via tsconfig path mapping where a worker initializer function could be exported from both a browser and server code variant (e.g., initialize-xyz-worker.server.ts & initialize-xyz-worker-browser.ts). Such an approach would also allow the removal of the runtime Worker conditional and encapsulate any server fallback behavior.

@alan-agius4 alan-agius4 added the action: merge The PR is ready for merge by the caretaker label May 27, 2021
…ver builds

Web-workers are not supported on the server and therefore we should not try include them in server builds.

Closes #20877
@filipesilva filipesilva merged commit 77f81dc into angular:master May 31, 2021
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Jul 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker target: patch This PR is targeted for the next patch release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Issue with Worker & SSR (universal)
3 participants