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

feat(CommonJsPlugin): magic comment to ignore require calls #11316

Merged
merged 5 commits into from
Jan 21, 2021

Conversation

petermetz
Copy link
Contributor

@petermetz petermetz commented Aug 12, 2020

A partial port of the same magic comments that are supported
for import() calls already via this commit:
f65e9da

Fixes #11311

Signed-off-by: Peter Somogyvari peter.metz@unarin.com

Motivation is in the issue comments that I linked above. Bottom line is that I'm using Typescript+Webpack+NodeJS and the import() calls get transpiled into require so the import ignore feature doesn't work for me I need the same for require() calls.

What kind of change does this PR introduce?

feature

Did you add tests for your changes?

Yes.

Does this PR introduce a breaking change?

Not that I'm aware of. It's a new feature.

What needs to be documented once your changes are merged?

You can enable magic comment for CommonJs with module.parser.javascript.commonjsMagicComments: true and in Rule.parser.commonjsMagicComments: true.
With that enabled you can use the webpackIgnore: true magic comment for require calls as well: https://webpack.js.org/api/module-methods/#commonjs

Some configuration options has been moved to parser objects as well:

  • module.{expr|wrapped|unknown}Context{Request|RegExp|Recursive|Critical}
  • module.strictExportPresence
  • module.strictThisContextOnImports
  • All have been moved to module.parser.javascript.xxx resp. Rule.parser.xxx
  • If that's not already in the docs: To get the parser options of a module the options in module.parser.[module-type] are merged with Rule.parser. The same for the generator options.
    • If the module type contains / the base module type options are also merged. e.g. for javascript/esm: module.parser.javascript + module.parser["javascript/esm"] + Rule.parser (could be multiple, if multiple rules match).

@jsf-clabot
Copy link

jsf-clabot commented Aug 12, 2020

CLA assistant check
Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

@webpack-bot
Copy link
Contributor

webpack-bot commented Aug 12, 2020

For maintainers only:

  • This needs to be documented (issue in webpack/webpack.js.org will be filed when merged)
  • This needs to be backported to webpack 4 (issue will be created when merged)

@petermetz
Copy link
Contributor Author

Note: It would be great if this could be back-ported to 4.x since AFAIK 5 is not out/stable yet.

@anshumanv
Copy link
Member

Note: It would be great if this could be back-ported to 4.x since AFAIK 5 is not out/stable yet.

Will take care of the backport 👍

@sokra
Copy link
Member

sokra commented Aug 13, 2020

Looks good. I wonder how this affects performance considering there are a lot more require()s compare to import()s in a codebase

@petermetz
Copy link
Contributor Author

Looks good. I wonder how this affects performance considering there are a lot more require()s compare to import()s in a codebase

@sokra It depends mostly on the performance characteristics of the comment parsing in the edge case when there are no comments to be parsed in the require() call (which is what will happen 99.9% of the time).
My guess is that the parser is already reasonably well optimized because it's such a central component, but you tell me.
If it turns out that it does cause a significant slowdown we could add a flag in the plugin's options that stops the parsing from happening unless explicitly enabled by that flag. Then the documentation can say that first you need to enable the plugin flag in the webpack config file and then you can start adding the magic comments in the code.

@sokra
Copy link
Member

sokra commented Aug 13, 2020

Yeah actually the getComments function in JavascriptParser is a bit inefficient.

Could you improve it by using binary search? The comments array should be sorted anyway...

@petermetz
Copy link
Contributor Author

petermetz commented Aug 13, 2020

Yeah actually the getComments function in JavascriptParser is a bit inefficient.

Could you improve it by using binary search? The comments array should be sorted anyway...

@sokra Would something like this be okay? => 04d6b0f

I left it in a separate commit because it doesn't really have anything to do with the magic comment feature itself, but happy to squash of course, just let me know.

EDIT: Updated commit link after force push

@webpack-bot
Copy link
Contributor

Hi @petermetz.

Just a little hint from a friendly bot about the best practice when submitting pull requests:

Don't submit pull request from your own master branch. It's recommended to create a feature branch for the PR.

You don't have to change it for this PR, just make sure to follow this hint the next time you submit a PR.

lib/javascript/JavascriptParser.js Outdated Show resolved Hide resolved
lib/util/binarySearch.js Outdated Show resolved Hide resolved
@webpack-bot
Copy link
Contributor

@petermetz Thanks for your update.

I labeled the Pull Request so reviewers will review it again.

@sokra Please review the new changes.

@petermetz petermetz force-pushed the master branch 3 times, most recently from 5fa8e15 to 3790c0b Compare August 14, 2020 22:35
petermetz added a commit to petermetz/cacti that referenced this pull request Nov 6, 2020
Depends on webpack/webpack#11316
This has no real effect until the PR above is
merged and releaed on Webpack
(and then we upgrade to that release for the builds)

How this fix works is explained in the linked PR
in greater detail.

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this pull request Nov 12, 2020
Depends on webpack/webpack#11316
This has no real effect until the PR above is
merged and releaed on Webpack
(and then we upgrade to that release for the builds)

How this fix works is explained in the linked PR
in greater detail.

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to hyperledger-cacti/cacti that referenced this pull request Dec 1, 2020
Depends on webpack/webpack#11316
This has no real effect until the PR above is
merged and releaed on Webpack
(and then we upgrade to that release for the builds)

How this fix works is explained in the linked PR
in greater detail.

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
@alexander-akait
Copy link
Member

@petermetz Sorry for delay, can you rebase?

A partial port of the same magic comments that are supported
for import() calls already via this commit:
webpack@f65e9da

Signed-off-by: Peter Somogyvari <peter.metz@unarin.com>
Signed-off-by: Peter Somogyvari <peter.metz@unarin.com>
@petermetz
Copy link
Contributor Author

@petermetz Sorry for delay, can you rebase?

@alexander-akait No worries at all. I did the rebase just now, enjoy!

move javascript related options from 'module' to 'module.parser.javascript'
@webpack-bot
Copy link
Contributor

Thank you for your pull request! The most important CI builds succeeded, we’ll review the pull request soon.

@sokra sokra closed this Jan 21, 2021
@sokra
Copy link
Member

sokra commented Jan 21, 2021

Thanks

@webpack-bot
Copy link
Contributor

I've created an issue to document this in webpack/webpack.js.org.

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

Successfully merging this pull request may close these issues.

webpackIgnore: true is ignored, dynamic import/require still processed
6 participants