-
Notifications
You must be signed in to change notification settings - Fork 100
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
Update dependency babel-preset-solid to v1.8.17 #2279
Open
renovate
wants to merge
1
commit into
main
Choose a base branch
from
renovate/babel-preset-solid-1.x
base: main
Could not load branches
Branch not found: {{ refName }}
Could not load tags
Nothing to show
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
renovate
bot
force-pushed
the
renovate/babel-preset-solid-1.x
branch
8 times, most recently
from
October 21, 2023 19:00
715e7fa
to
a99a092
Compare
renovate
bot
changed the title
Update dependency babel-preset-solid to v1.8.2
Update dependency babel-preset-solid to v1.8.4
Oct 26, 2023
renovate
bot
force-pushed
the
renovate/babel-preset-solid-1.x
branch
2 times, most recently
from
October 28, 2023 10:53
b83742a
to
0394939
Compare
renovate
bot
force-pushed
the
renovate/babel-preset-solid-1.x
branch
from
November 17, 2023 01:22
0394939
to
16f6465
Compare
renovate
bot
changed the title
Update dependency babel-preset-solid to v1.8.4
Update dependency babel-preset-solid to v1.8.6
Nov 23, 2023
renovate
bot
force-pushed
the
renovate/babel-preset-solid-1.x
branch
from
November 23, 2023 03:14
16f6465
to
175eb10
Compare
renovate
bot
force-pushed
the
renovate/babel-preset-solid-1.x
branch
2 times, most recently
from
December 16, 2023 04:47
3b25cf5
to
57cdabb
Compare
renovate
bot
force-pushed
the
renovate/babel-preset-solid-1.x
branch
from
January 3, 2024 22:40
57cdabb
to
3764159
Compare
renovate
bot
changed the title
Update dependency babel-preset-solid to v1.8.6
Update dependency babel-preset-solid to v1.8.8
Jan 3, 2024
renovate
bot
force-pushed
the
renovate/babel-preset-solid-1.x
branch
from
January 9, 2024 01:22
3764159
to
2dca645
Compare
renovate
bot
changed the title
Update dependency babel-preset-solid to v1.8.8
Update dependency babel-preset-solid to v1.8.9
Jan 9, 2024
renovate
bot
force-pushed
the
renovate/babel-preset-solid-1.x
branch
4 times, most recently
from
January 9, 2024 17:35
24b164a
to
c3ab210
Compare
renovate
bot
force-pushed
the
renovate/babel-preset-solid-1.x
branch
from
January 23, 2024 01:40
c3ab210
to
d47afb7
Compare
renovate
bot
changed the title
Update dependency babel-preset-solid to v1.8.9
Update dependency babel-preset-solid to v1.8.12
Jan 23, 2024
renovate
bot
force-pushed
the
renovate/babel-preset-solid-1.x
branch
from
February 14, 2024 21:19
d47afb7
to
1732aab
Compare
renovate
bot
changed the title
Update dependency babel-preset-solid to v1.8.12
Update dependency babel-preset-solid to v1.8.15
Feb 14, 2024
renovate
bot
force-pushed
the
renovate/babel-preset-solid-1.x
branch
from
February 27, 2024 03:28
1732aab
to
cbaff60
Compare
renovate
bot
force-pushed
the
renovate/babel-preset-solid-1.x
branch
from
February 29, 2024 17:53
cbaff60
to
2060f84
Compare
renovate
bot
force-pushed
the
renovate/babel-preset-solid-1.x
branch
9 times, most recently
from
March 20, 2024 01:27
799a61f
to
e16e64d
Compare
renovate
bot
changed the title
Update dependency babel-preset-solid to v1.8.15
Update dependency babel-preset-solid to v1.8.16
Mar 20, 2024
renovate
bot
force-pushed
the
renovate/babel-preset-solid-1.x
branch
from
April 23, 2024 02:18
e16e64d
to
1dfc9b4
Compare
renovate
bot
changed the title
Update dependency babel-preset-solid to v1.8.16
Update dependency babel-preset-solid to v1.8.17
Apr 23, 2024
renovate
bot
force-pushed
the
renovate/babel-preset-solid-1.x
branch
from
May 8, 2024 23:09
1dfc9b4
to
cef4974
Compare
renovate
bot
force-pushed
the
renovate/babel-preset-solid-1.x
branch
from
May 8, 2024 23:13
cef4974
to
6c5c383
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
None yet
0 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
1.6.7
->1.8.17
Release Notes
solidjs/solid (babel-preset-solid)
v1.8.16
Compare Source
v1.8.15
Compare Source
v1.8.12
Compare Source
v1.8.9
Compare Source
v1.8.8
Compare Source
v1.8.6
Compare Source
v1.8.4
Compare Source
v1.8.2
Compare Source
v1.8.0
Compare Source
I admit this is not the most exciting release from a feature standpoint. We are in that holding pattern between the end of 1.x and the start of 2.0. We recently made our new reactive experiments public and continue to build those out in public with @solidjs/signals.
This version is more about addressing some of the fundamentals that will help us in other projects like SolidStart while we do the transition. A big part of this is applying what we have learned when doing performance benchmarks for the work that has been funded by Google Chrome Aurora.
Async and Resources need work and are too all in. It is great to have a solution but now that we have a better understanding we need to start breaking things apart into their fundamental pieces.
De-duping Streaming Serialization
This is the marquee feature of this release and is largely the work of @lxsmnsyc. Solid has been able to serialize promises and do streaming for a couple of years now, but it was very special-cased. Now it is a generic mechanism.
This matters because it means that we have decoupled the promise serialization from Resources, and in so decoupled the whole when the stream is done from them. This opens up things like nested promises.
More so we have a mechanism now that deeply de-dupes data serialized across flushes. This is important for features like Islands where you might pass the same props to multiple Islands across different Suspense boundaries and don't want to send the data more than once. And even examples where that data can be accessed at varying depths (recursive comments in say a Hackernews site).
Hydration Improvements
Fragments for Hydration have been a bit of a pain and we keep seeming to have different issues reported around element duplication. Most commonly this has been around where there are
lazy
component siblings or where the fragment is top-level. After looking into and fixing an issue for Astro I decided to look at some of the oldest bugs in Solid and found it was a similar bug.In many cases, the DOM can change throughout Hydration while doing things like streaming but we need to pause and resume hydration because code isn't available yet. While we don't create elements during hydration, getting an accurate snapshot of the DOM for the current state for future list reconciliation is a process we've had a few tries at but in 1.8 we update this in a way that makes sure it doesn't get out of date.
Also in 1.8, we have added some performance improvements to hydration in the form of not redundantly setting attributes or props as the page hydrates similar to how we don't update text. This is all migration towards a future where we don't need to do as much hydration, but it is important to note that values will be kept as they were on the server rather than how they may compute at runtime during hydration.
Smaller Templates
In 1.7 we removed unnecessary closing tags from template strings. It was a bit painful because we were a bit overzealous at first. While I believe in the end we got to a good place, ultimately all but the simplest reductions have been hidden behind a compiler flag(
omitNestedClosingTags
). Thanks to work from @intrnl we are implementing another template size reduction technique of removing unnecessary quotes. Quotes are actually not required by HTML in some cases and it can add up.Other
Fix NGINX Server Side Includes
Comments led with
#
are treated as special directives for a few different servers so we've needed to change our open hydration markers to$
. As usual, your version of Solid and the Babel Plugin should be the same to ensure this matches up.Better Guards on Global Scripts
Solid uses an inline HydrationScript as a way to do processing before the framework and code have loaded. To handle things like event capture and streaming. However, we didn't do a good job of guarding the right thing when multiple were added to the same page, a situation that can happen in Micro-frontends or 3rd party Islands solutions. Now the script guards against duplicate inclusion.
v1.7.12
Compare Source
v1.7.7
Compare Source
v1.7.4
Compare Source
v1.7.3
Compare Source
v1.7.2
Compare Source
v1.7.1
Compare Source
v1.7.0
Compare Source
Solid has experienced incredible growth in usage the last 6 months. Companies are using it to power production applications and SolidStart Beta has been a big part of that. As a natural part of this growth and increased use at scale we are continuing to learn what works well and what the rough edges in Solid are today.
This v1.7 release marks the beginning of the migration roadmap to v2.0. We are beginning to re-evaluate core APIs and will begin introducing new ones while reasonably deprecating older ones in a manner that eases breaking changes. Our intention is to ease the broader ecosystem into preparing for improvements that a major 2.0 will unlock for the whole community.
Improved TypeScript
Null-Asserted Control Flow
One of the pains of using Solid with TypeScript has been that JSX control flows can't really type narrow. This is true, but starting with the migration to explicit
keyed
in v1.5 we now complete this story by introducing callback forms for<Show>
and<Match>
that work when non-keyed.The main difference is the callback form instead of passing in the value as it does when
keyed
, passes in a function that is type narrowed.Keep in mind because we are non-null asserting the input signal so it won't expect null in closures that execute when the condition is no longer satisfied. For this reason the accessor from the callback is special and will throw when attempted to be accessed when the condition is no longer true. This may be unexpected but it is our best attempt to keep TypeScript strict and not present inconsistency in reactivity. Luckily this only applies to things like timers which you should be cleaning up anyway and not things like event handlers. We recommend using the original conditions source in those closures if you must.
Better Event Types for Input Elements
This has irked people for a while but we come by it honestly,
target
is gives you a type ofElement
rather than the specific element that is the target. That means no access to.value
or.checked
. The reason is there is no way to know at compile time what the target of an event will be. ThecurrentTarget
will be the element you attach the event to but the target can be anything.There is a way to work around this though, in that if we know the
currentTarget
is of type that generates the event and that thecurrentTarget
is the the type of this element we can assume it is thetarget
as well. Not perfect logic but it is what React does and we do too.Now
onInput
,onChange
,onBlur
,onFocus
,onFocusIn
, andonFocusOut
all support more detailedtarget
when applied toHTMLInputElement
,HTMLTextAreaElement
, andHTMLSelectElement
.Stricter JSX Elements
Strict JSX elements have been tricky because we have to acknowledge at a certain point that TypeScript is to serve our purposes rather than to represent all possible values that could work. For us the ambiguity lies in functions.
Solid's JSX needs to accept functions to handle dynamic insertion. However, in authoring it leads to awkward situations.
The first you hit the first time use Solid. You create that counter and don't call
count
as a function and it works.This example works in some places and not others which might lead to the wrong conclusions.
The second place you might hit this is when you get a little further on your journey and decide you need a component to re-render and decide that you can just wrap the whole thing in a function:
Again this seems fine, except the fact that every time
count
changes you are recreating all the DOM Elements even when it resolves to the same conditional.Eventually you might even not think twice about passing functions into children of arbitrary components:
But what does this do? When is the function called?
As it turns out removing functions from
JSX.Element
type makes all of these scenarios error. Components only expect the values dictated by their types.The tradeoff here is that authoring components you can no longer just return a Signal or Memo without casting. If using JSX you can always return a Fragment.
If not you will need to cast to
unknown as JSX.Element
.Better Errors and Cleanup
catchError
replacesonError
Error Handling is complicated enough without having to try to guess how they propagate.
onError
admittedly is a lower level primitive but fundamentally had this flaw. It worked by registering an error handler on the parent scope, but left it ambiguous how to handle siblings. Is it a queue? Are they independent?As a result we are introducing
catchError
in this release which introduces its own scope to catch any errors below it. The first argument in the primitive is similar to the try and the second argument is the catch.onError
will still be present until it can be removed in a future major version.Standardized Errors
Error Handling has had many weird edge cases introduced by applications throwing unusual values. In v1.7 we wrap all thrown values that aren't of type
Error
in anew Error
and attach the original thrown value as.cause
.More Performant Dev Tools
Now that Solid Dev Tools have been stabilizing, we have a much better idea what support we need for them. In so we were able to remove the very costly serialization we were doing for generating unique identifiers. Conventions around naming and exports were streamlined and standardized as well.
Others
prop:
andattr:
in Spreadsreadonly
) to custom elementssolid-ssr
to type"module"
v1.6.16
Compare Source
v1.6.13
Compare Source
v1.6.12
Compare Source
v1.6.10
Compare Source
v1.6.9
Compare Source
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate. View repository job log here.