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(plugin-webpack): customize HtmlWebpackPlugin options #2969

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

sgammon
Copy link

@sgammon sgammon commented Oct 16, 2022

  • I have read the contribution documentation for this project.
  • I agree to follow the code of conduct that this project follows, as appropriate.
  • The changes are appropriately documented (if applicable).
  • The changes have sufficient test coverage (if applicable).
  • The testsuite passes successfully on my local machine (if applicable).

Summarize your changes:

This changeset adds options to entrypoints to support customized operation of the HtmlWebpackPlugin. See below for full changeset.

Changes enclosed:

  • Add properties for output, htmlPlugins, and htmlOptions to WebpackPluginEntryPoint
  • Use new options from Config.ts, by merging them into their expected places

Fixes and closes #2968.

@sgammon sgammon force-pushed the feat/customize-html branch from 0ba5296 to 1b8ae31 Compare October 16, 2022 03:53
@sgammon
Copy link
Author

sgammon commented Oct 16, 2022

i see what seems like a flaky test locally (unrelated), and i'm unclear about how i might reach into the HtmlWebpackPlugin to test some of these options, so i left it at a test for output. i'm happy to amend to update docs and tests.

@codecov
Copy link

codecov bot commented Oct 16, 2022

Codecov Report

Merging #2969 (6565ca7) into main (362099a) will increase coverage by 0.03%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #2969      +/-   ##
==========================================
+ Coverage   73.80%   73.84%   +0.03%     
==========================================
  Files          66       66              
  Lines        2142     2145       +3     
  Branches      424      427       +3     
==========================================
+ Hits         1581     1584       +3     
  Misses        356      356              
  Partials      205      205              
Impacted Files Coverage Δ
packages/plugin/webpack/src/WebpackConfig.ts 98.76% <100.00%> (+0.04%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 362099a...6565ca7. Read the comment docs.

@erickzhao erickzhao changed the title Feature: Customize Webpack HTML feat(plugin-webpack): customize HtmlWebpackPlugin options Oct 16, 2022
Comment on lines +61 to +67
/**
* Additional options to merge into the Webpack `output` configuration for this entry-
* point.
*/
output?: object;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not clear on the use case for this option, it directly contradicts the goals of forge which is to manage these disk assets (E.g. we don't allow configuration of out/dir for other tools) specifically so we're always in control of and know where things are on disk. i.e. this will break the environment variables that we provide for folks to get the path to the webpack generated files

Can you clarify exactly what you want to pass in here and why?

Copy link
Author

@sgammon sgammon Oct 16, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes -- in some cases, plugin adopters need to adjust the output parameter in concert with a hook into the build. for example, the SRI plugin needs {output: {crossorigin: 'anonymous'}}, but only for targets which invoke HtmlWebpackPlugin.

i did what i could to avoid this object, but i don't see an alternative -- any ideas? specifically, for applying options to the output stanza of only the HTML targets?

Comment on lines +56 to +62
/**
* Plugins to include before `HtmlWebpackPlugin`; typically, HTML plugin add-ons will
* need to be placed here.
*/
htmlPlugins?: WebpackPluginInstance[];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of passing in a random list of plugins here, could we just change our implementation to ensure the config is extended with user plugins appearing first in the list instead of always adding ours before? That would avoid this extra configuration option completely

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the intent of isolating this as its own property instead of adjusting the plugin flow is three-fold:

1) less invasive.
i suspect downstream projects rely on the order of plugins, so i am doing my best not to adjust the existing execution order in any way that might affect how existing projects work.

2) no way to include only where HTML targets exist.
for example, say you have several targets, a few with exotic renderers or something, and then just one target with HtmlWebpackPlugin. if you use the global plugins property, it will apply to all entries instead of just the applicable invocation of HtmlWebpackPlugin.

3) semantic meaning.
because these are the only plugins that must run before HtmlWebpackPlugin, this should keep the plugin flow easy to reason about for future changes.

these are just the thoughts behind this approach. i am totally open to thoughts on better typing or alternate approaches.

packages/plugin/webpack/src/Config.ts Outdated Show resolved Hide resolved
packages/plugin/webpack/src/WebpackConfig.ts Outdated Show resolved Hide resolved
packages/plugin/webpack/src/WebpackConfig.ts Outdated Show resolved Hide resolved
@sgammon sgammon force-pushed the feat/customize-html branch from 1b8ae31 to 07f8368 Compare October 16, 2022 07:28
This changeset adds options to entrypoints to support customized
operation of the `HtmlWebpackPlugin`. See below for full changeset.

Changes enclosed:
- Add properties for `output`, `htmlPlugins`, and `htmlOptions` to
  `WebpackPluginEntryPoint`
- Use new options from `Config.ts`, by merging them into their
  expected places
- Add tests to cover new options

Fixes and closes electron#2968.
@sgammon sgammon force-pushed the feat/customize-html branch from 07f8368 to 6565ca7 Compare October 16, 2022 07:42
...(entryPoint.html
? [
new HtmlWebpackPlugin({
...(entryPoint.htmlOptions || {}),
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reworked to use spread operator

name: 'main',
js: 'rendererScript.js',
output: {
crossorigin: 'anonymous',
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

test showing sample use of output

@sgammon
Copy link
Author

sgammon commented Oct 16, 2022

i should also say, @MarshallOfSound, i have some background material on the linked issue, #2698. the alternatives listed there were considered but imagined to be suboptimal. thank you for all your hard work on this library, and for the lightning fast review -- it makes working with Electron so easy and smooth!

@sgammon sgammon closed this Oct 16, 2022
@sgammon
Copy link
Author

sgammon commented Oct 16, 2022

accidental close (fat thumb)

@sgammon sgammon reopened this Oct 16, 2022
@erickzhao erickzhao requested a review from a team October 17, 2022 17:26
@erickzhao erickzhao marked this pull request as ready for review October 17, 2022 17:26
@Pajn
Copy link

Pajn commented Sep 21, 2023

What is blocking this PR from beeing merged? It would be very useful for us 🙏🏼

@elvince
Copy link

elvince commented Feb 9, 2024

Hi,
Can we expect to have something merge on this?
I bet it will be useful for a lot of us, and it could helps to send our own variables to our template, which is not the cas as of today.
thanks,

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.

Customizable options for HtmlWebpackPlugin
5 participants