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

FIXES #713 Remove 'use strict' strings brute force to enable module packaging #1664

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

laurisvan
Copy link

Summary

The current ExcelJS fails with CSP unsafe code evaluation when exceljs is bundled with recent WebPack versions. It appears that the root cause is regenerator-runtime resorting to 'eval':ing the source code whenever it encounters "use strict". This is probably because "use strict" shouldn't be necessary with ES modules (they are strict by default).

I tried various workarounds, such as replacing all "use strict" clauses when babelifying code, having similar replacements with browserify etc. I am almost sure the root cause relates to browserify, e.g. it somehow ends up adding the "use strict" clauses. In absence of a better solution, I thought that brute force removal of "use strict" strings was the only option left, so I added a Grunt task for that. I tried the more popular "grunt-replace" module for this, but unfortunately it failed to process some of the libraries included (because of @@ character somewhere within the code).

I think the long term solution would be to replace the current build system with some other than browserify that would supply the needed polyfills, but I believe such an architectural change would be much bigger undertaking.

Test plan

Steps to repeat:

  1. Include the module in a Webpack build, insert new CspHtmlWebpackPlugin(cspConfigPolicy, cspOptions) into plugins array
  2. npm link the exceljs module into your project
  3. Build and load the web page

Related to source code (for typings update)

N/A

@laurisvan
Copy link
Author

Note: we have been running this in production since submitting this MR. I would respect if we could get it into mainline, or at least a suggestion of an alternative for how to fix this blocking issue.

@dmathisen
Copy link

dmathisen commented Jun 7, 2023

For anyone stumbling across this and is experiencing the unsafe-eval issue, it could be related to #713

It's still an issue, but there are a few suggested fixes (see here and here). The second one (my comment) worked for me and, to me, seems to be the lowest impact fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants