Support Trusted Types in EvalSourceMapDevToolPlugin #14075
Comments
|
Yep, PR welcome |
|
@alexander-akait , could you please review the PR for me? Thanks. |
|
Hello @alexander-akait , any update on the PR? Thanks. |
|
@alexander-akait , @sokra , can we pls get a feedback on #14173? Happy to change the approach if you have any suggestions. Thank you. |
|
Fixed #14173 |
6 tasks
6 tasks
kodiakhq bot
pushed a commit
to vercel/next.js
that referenced
this issue
May 22, 2022
Linked to issue #32209. ## Feature - [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [x] Related issues linked using `fixes #number` - [ ] Integration tests added - [ ] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [ ] Errors have helpful link attached, see `contributing.md` ## Documentation The purpose of this PR is to enable Trusted Types compatibility in Webpack. When the app is run in development mode, Webpack is currently set to use an [eval-source-map](https://github.com/vercel/next.js/blob/5a16b1a26f6c213776deed9ac465e2bc81cdf5f3/packages/next/build/webpack/config/blocks/base.ts#L33). This source map involves passing raw strings to `eval()` calls, which raise Trusted Types violations. The solution to this problem is to set `webpack5Config.output.trustedTypes` in the Webpack config. As shown in the documentation [here](https://webpack.js.org/configuration/output/#outputtrustedtypes), setting this value to a string will create a Trusted Types policy with the specified name. By creating a policy within Webpack, the raw strings passed to the `eval()` calls will be promoted to be of type `TrustedScript`. The issue where this was addressed in Webpack can be found [here](webpack/webpack#14075). ### Note: The policy name that is set in the Webpack config is currently `nextjs#bundler`. Once it is released to the public and application developers begin using it, it may be harder to change the value since any application developers with a custom policy name allowlist would now need to update their next.config.js headers to allow this new name. Thus, a good name should ideally be determined before this pull request is merged. The reason that `nextjs#bundler` is preferred over `nextjs#webpack` is in case Next.js moves to a different bundler in the future. Having a generic name would allow for application developers to keep their next.config.js file the same after the bundler switch has occurred. If a different name is preferred, feel free to comment what that would be. The code was tested in a sample application to ensure it behaved as expected. Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature request
What is the expected behavior?
Say webpack is configured with output.trustedTypes = true and devtool = "eval-cheap-module-source-map". I expect that generated code can still use
evalbut the script will be created using createScript method from Trusted Types policy.What is motivation or use case for adding/changing the behavior?
This is needed when working with Trusted Types during local development. Passing
stringargument intoeval()is forbidden when you enforcerequire-trusted-types-for 'script'CSP directive. This is exactly whatEvalSourceMapDevToolPluginis doing and therefore it is hard to debug such application locally.How should this be implemented in your opinion?
We could probably follow similar approach as with
CreateScriptUrlRuntimeModuleand based on whether trusted types are enabled or not return either raw string or output ofpolicy.createScript(). This value can then be passed toeval().Are you willing to work on this yourself?
yes
The text was updated successfully, but these errors were encountered: