-
-
Notifications
You must be signed in to change notification settings - Fork 384
feat(ordering): add support for insertInto option #371
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think better implement ability to declare own function with insert logic, it is allow to insert something in Shadow Dom or when you need more complex logic we do same in style loader in next major release
@evilebottnawi So just do something like
If so, I can make that update |
@brophdawg11 yes, we do same for |
This adds an new `insertInto` option that is optional and backards-compatible. Specifying a CSS selector allows the user to specify a DOM node into which the async-loaded <link> tags should be inserted. Closes webpack-contrib#370, related to webpack-contrib#328,webpack-contrib#331
@evilebottnawi Sorry for the delay - I just updated this to take a function instead of a selector based on your comment above |
I think it would be great if we can have the same behavior for |
👋 folks, I put up a similar PR to introduce the |
Close in favor #459 |
Yep - thanks @giuseppeg! I agree this is more flexible and better aligns with |
This PR contains a:
Motivation / Use-Case
The issue being addressed is describe in #370. This adds a new
insertInto
option that is optional and backwards compatible. Specifying a CSS selector allows the user to specify a DOM node into which the async-loaded<link>
tags should be inserted.Breaking Changes
n/a, changes are backwards compatible and will continue to insert
<link>
tags into the<head>
if noinsertInto
option is specifiedAdditional Info
This is a different approach that solves (I think) the same problem as #331, in a more customizable and backwards-compatible way.
This is also seemingly related to #328.