-
-
Notifications
You must be signed in to change notification settings - Fork 11
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 Serverless (JS) #119
Merged
Merged
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
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
April 2, 2024 06:19
a2aa16e
to
b41ce2f
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
April 5, 2024 23:01
b41ce2f
to
697aa26
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
April 7, 2024 19:32
697aa26
to
5b466ec
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
April 8, 2024 09:02
5b466ec
to
7f0c640
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
April 8, 2024 21:18
7f0c640
to
ecff4fb
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
April 9, 2024 01:38
ecff4fb
to
7defa23
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
April 12, 2024 08:39
7defa23
to
233ffb7
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
April 12, 2024 23:34
233ffb7
to
088e38e
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
April 14, 2024 12:32
088e38e
to
047046a
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
April 14, 2024 23:07
047046a
to
b9acc02
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
April 19, 2024 23:06
b9acc02
to
11534dd
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
April 21, 2024 09:37
11534dd
to
abd9a61
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
April 25, 2024 08:48
abd9a61
to
4870d14
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
April 28, 2024 20:22
4870d14
to
1b8e7b8
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
May 11, 2024 13:27
381b817
to
a269766
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
May 11, 2024 20:01
a269766
to
e06d902
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
May 13, 2024 20:16
e06d902
to
8c6d7a8
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
May 16, 2024 00:31
8c6d7a8
to
af08036
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
May 16, 2024 20:42
af08036
to
8f2a614
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
May 17, 2024 22:03
8f2a614
to
0f2d910
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
May 18, 2024 21:26
0f2d910
to
a268203
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
May 19, 2024 16:38
a268203
to
07c158b
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
May 24, 2024 07:21
07c158b
to
ad48565
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
May 25, 2024 22:12
ad48565
to
aca2518
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
May 26, 2024 19:32
aca2518
to
56a3821
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
May 28, 2024 04:11
56a3821
to
e634d4d
Compare
renovate
bot
force-pushed
the
renovate/serverless-(js)
branch
from
May 31, 2024 07:40
e634d4d
to
086cdf4
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
3.521.0
->3.583.0
8.10.134
->8.10.138
18.19.18
->18.19.33
0.20.1
->0.21.4
1.51.0
->1.52.1
29.1.2
->29.1.4
Release Notes
aws/aws-sdk-js-v3 (@aws-sdk/client-s3)
v3.583.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.582.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.577.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.576.0
Compare Source
Features
v3.575.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.574.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.572.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.569.0
Compare Source
Bug Fixes
v3.568.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.567.0
Compare Source
Features
v3.565.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.564.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.563.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.556.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.554.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.552.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.550.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.549.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.540.0
Compare Source
Bug Fixes
v3.537.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.536.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.535.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.534.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.533.0
Compare Source
Features
3.529.1 (2024-03-08)
Note: Version bump only for package @aws-sdk/client-s3
v3.529.1
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.529.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.525.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
v3.523.0
Compare Source
Note: Version bump only for package @aws-sdk/client-s3
evanw/esbuild (esbuild)
v0.21.4
Compare Source
Update support for import assertions and import attributes in node (#3778)
Import assertions (the
assert
keyword) have been removed from node starting in v22.0.0. So esbuild will now strip them and generate a warning with--target=node22
or above:Import attributes (the
with
keyword) have been backported to node 18 starting in v18.20.0. So esbuild will no longer strip them with--target=node18.N
ifN
is 20 or greater.Fix
for await
transform when a label is presentThis release fixes a bug where the
for await
transform, which wraps the loop in atry
statement, previously failed to also move the loop's label into thetry
statement. This bug only affects code that uses both of these features in combination. Here's an example of some affected code:Do additional constant folding after cross-module enum inlining (#3416, #3425)
This release adds a few more cases where esbuild does constant folding after cross-module enum inlining.
Pass import attributes to on-resolve plugins (#3384, #3639, #3646)
With this release, on-resolve plugins will now have access to the import attributes on the import via the
with
property of the arguments object. This mirrors thewith
property of the arguments object that's already passed to on-load plugins. In addition, you can now passwith
to theresolve()
API call which will then forward that value on to all relevant plugins. Here's an example of a plugin that can now be written:Formatting support for the
@position-try
rule (#3773)Chrome shipped this new CSS at-rule in version 125 as part of the CSS anchor positioning API. With this release, esbuild now knows to expect a declaration list inside of the
@position-try
body block and will format it appropriately.Always allow internal string import and export aliases (#3343)
Import and export names can be string literals in ES2022+. Previously esbuild forbid any usage of these aliases when the target was below ES2022. Starting with this release, esbuild will only forbid such usage when the alias would otherwise end up in output as a string literal. String literal aliases that are only used internally in the bundle and are "compiled away" are no longer errors. This makes it possible to use string literal aliases with esbuild's
inject
feature even when the target is earlier than ES2022.v0.21.3
Compare Source
Implement the decorator metadata proposal (#3760)
This release implements the decorator metadata proposal, which is a sub-proposal of the decorators proposal. Microsoft shipped the decorators proposal in TypeScript 5.0 and the decorator metadata proposal in TypeScript 5.2, so it's important that esbuild also supports both of these features. Here's a quick example:
This proposal has been marked as "stage 3" which means "recommended for implementation". However, it's still a work in progress and isn't a part of JavaScript yet, so keep in mind that any code that uses JavaScript decorator metadata may need to be updated as the feature continues to evolve. If/when that happens, I will update esbuild's implementation to match the specification. I will not be supporting old versions of the specification.
Fix bundled decorators in derived classes (#3768)
In certain cases, bundling code that uses decorators in a derived class with a class body that references its own class name could previously generate code that crashes at run-time due to an incorrect variable name. This problem has been fixed. Here is an example of code that was compiled incorrectly before this fix:
Fix
tsconfig.json
files inside symlinked directories (#3767)This release fixes an issue with a scenario involving a
tsconfig.json
file thatextends
another file from within a symlinked directory that uses thepaths
feature. In that case, the implicitbaseURL
value should be based on the real path (i.e. after expanding all symbolic links) instead of the original path. This was already done for other files that esbuild resolves but was not yet done fortsconfig.json
because it's special-cased (the regular path resolver can't be used because the information insidetsconfig.json
is involved in path resolution). Note that this fix no longer applies if the--preserve-symlinks
setting is enabled.v0.21.2
Compare Source
Correct
this
in field and accessor decorators (#3761)This release changes the value of
this
in initializers for class field and accessor decorators from the module-levelthis
value to the appropriatethis
value for the decorated element (either the class or the instance). It was previously incorrect due to lack of test coverage. Here's an example of a decorator that doesn't work without this change:Allow
es2023
as a target environment (#3762)TypeScript recently added
es2023
as a compilation target, so esbuild now supports this too. There is no difference between a target ofes2022
andes2023
as far as esbuild is concerned since the 2023 edition of JavaScript doesn't introduce any new syntax features.v0.21.1
Compare Source
Fix a regression with
--keep-names
(#3756)The previous release introduced a regression with the
--keep-names
setting and object literals withget
/set
accessor methods, in which case the generated code contained syntax errors. This release fixes the regression:v0.21.0
Compare Source
This release doesn't contain any deliberately-breaking changes. However, it contains a very complex new feature and while all of esbuild's tests pass, I would not be surprised if an important edge case turns out to be broken. So I'm releasing this as a breaking change release to avoid causing any trouble. As usual, make sure to test your code when you upgrade.
Implement the JavaScript decorators proposal (#104)
With this release, esbuild now contains an implementation of the upcoming JavaScript decorators proposal. This is the same feature that shipped in TypeScript 5.0 and has been highly-requested on esbuild's issue tracker. You can read more about them in that blog post and in this other (now slightly outdated) extensive blog post here: https://2ality.com/2022/10/javascript-decorators.html. Here's a quick example:
Note that this feature is different than the existing "TypeScript experimental decorators" feature that esbuild already implements. It uses similar syntax but behaves very differently, and the two are not compatible (although it's sometimes possible to write decorators that work with both). TypeScript experimental decorators will still be supported by esbuild going forward as they have been around for a long time, are very widely used, and let you do certain things that are not possible with JavaScript decorators (such as decorating function parameters). By default esbuild will parse and transform JavaScript decorators, but you can tell esbuild to parse and transform TypeScript experimental decorators instead by setting
"experimentalDecorators": true
in yourtsconfig.json
file.Probably at least half of the work for this feature went into creating a test suite that exercises many of the proposal's edge cases: https://github.com/evanw/decorator-tests. It has given me a reasonable level of confidence that esbuild's initial implementation is acceptable. However, I don't have access to a significant sample of real code that uses JavaScript decorators. If you're currently using JavaScript decorators in a real code base, please try out esbuild's implementation and let me know if anything seems off.
This proposal has been in the works for a very long time (work began around 10 years ago in 2014) and it is finally getting close to becoming part of the JavaScript language. However, it's still a work in progress and isn't a part of JavaScript yet, so keep in mind that any code that uses JavaScript decorators may need to be updated as the feature continues to evolve. The decorators proposal is pretty close to its final form but it can and likely will undergo some small behavioral adjustments before it ends up becoming a part of the standard. If/when that happens, I will update esbuild's implementation to match the specification. I will not be supporting old versions of the specification.
Optimize the generated code for private methods
Previously when lowering private methods for old browsers, esbuild would generate one
WeakSet
for each private method. This mirrors similar logic for generating oneWeakSet
for each private field. Using a separateWeakMap
for private fields is necessary as their assignment can be observable:This prints
true false
because this partially-initialized instance has#x
but not#y
. In other words, it's not true that all class instances will always have all of their private fields. However, the assignment of private methods to a class instance is not observable. In other words, it's true that all class instances will always have all of their private methods. This means esbuild can lower private methods into code where all methods share a singleWeakSet
, which is smaller, faster, and uses less memory. Other JavaScript processing tools such as the TypeScript compiler already make this optimization. Here's what this change looks like:Fix an obscure bug with lowering class members with computed property keys
When class members that use newer syntax features are transformed for older target environments, they sometimes need to be relocated. However, care must be taken to not reorder any side effects caused by computed property keys. For example, the following code must evaluate
a()
thenb()
thenc()
:Previously esbuild did this by shifting the computed property key forward to the next spot in the evaluation order. Classes evaluate all computed keys first and then all static class elements, so if the last computed key needs to be shifted, esbuild previously inserted a static block at start of the class body, ensuring it came before all other static class elements:
However, this could cause esbuild to accidentally generate a syntax error if the computed property key contains code that isn't allowed in a static block, such as an
await
expression. With this release, esbuild fixes this problem by shifting the computed property key backward to the previous spot in the evaluation order instead, which may push it into theextends
clause or even before the class itself:Fix some
--keep-names
edge casesThe
NamedEvaluation
syntax-directed operation in the JavaScript specification gives certain anonymous expressions aname
property depending on where they are in the syntax tree. For example, the following initializers convey aname
value:When you enable esbuild's
--keep-names
setting, esbuild generates additional code to represent thisNamedEvaluation
operation so that the value of thename
property persists even when the identifiers are renamed (e.g. due to minification).However, I recently learned that esbuild's implementation of
NamedEvaluation
is missing a few cases. Specifically esbuild was missing property definitions, class initializers, logical-assignment operators. These cases should now all be handled:v0.20.2
Compare Source
Support TypeScript experimental decorators on
abstract
class fields (#3684)With this release, you can now use TypeScript experimental decorators on
abstract
class fields. This was silently compiled incorrectly in esbuild 0.19.7 and below, and was an error from esbuild 0.19.8 to esbuild 0.20.1. Code such as the following should now work correctly:JSON loader now preserves
__proto__
properties (#3700)Copying JSON source code into a JavaScript file will change its meaning if a JSON object contains the
__proto__
key. A literal__proto__
property in a JavaScript object literal sets the prototype of the object instead of adding a property named__proto__
, while a literal__proto__
property in a JSON object literal just adds a property named__proto__
. With this release, esbuild will now work around this problem by converting JSON to JavaScript with a computed property key in this case:Improve dead code removal of
switch
statements (#3659)With this release, esbuild will now remove
switch
statements in branches when minifying if they are known to never be evaluated:Empty enums should behave like an object literal (#3657)
TypeScript allows you to create an empty enum and add properties to it at run time. While people usually use an empty object literal for this instead of a TypeScript enum, esbuild's enum transform didn't anticipate this use case and generated
undefined
instead of{}
for an empty enum. With this release, you can now use an empty enum to generate an empty object literal.Handle Yarn Plug'n'Play edge case with
tsconfig.json
(#3698)Previously a
tsconfig.json
file thatextends
another file in a package with anexports
map failed to work when Yarn's Plug'n'Play resolution was active. This edge case should work now starting with this release.Work around issues with Deno 1.31+ (#3682)
Version 0.20.0 of esbuild changed how the esbuild child process is run in esbuild's API for Deno. Previously it used
Deno.run
but that API is being removed in favor ofDeno.Command
. As part of this change, esbuild is now calling the newunref
function on esbuild's long-lived child process, which is supposed to allow Deno to exit when your code has finished running even though the child process is still around (previously you had to explicitly call esbuild'sstop()
function to terminate the child process for Deno to be able to exit).However, this introduced a problem for Deno's testing API which now fails some tests that use esbuild with
error: Promise resolution is still pending but the event loop has already resolved
. It's unclear to me why this is happening. The call tounref
was recommended by someone on the Deno core team, and calling Node's equivalentunref
API has been working fine for esbuild in Node for a long time. It could be that I'm using it incorrectly, or that there's some reference counting and/or garbage collection bug in Deno's internals, or that Deno'sunref
just works differently than Node'sunref
. In any case, it's not good for Deno tests that use esbuild to be failing.In this release, I am removing the call to
unref
to fix this issue. This means that you will now have to call esbuild'sstop()
function to allow Deno to exit, just like you did before esbuild version 0.20.0 when this regression was introduced.Note: This regression wasn't caught earlier because Deno doesn't seem to fail tests that have outstanding
setTimeout
calls, which esbuild's test harness was using to enforce a maximum test runtime. Adding asetTimeout
was allowing esbuild's Deno tests to succeed. So this regression doesn't necessarily apply to all people using tests in Deno.floydspace/serverless-esbuild (serverless-esbuild)
v1.52.1
Compare Source
Bug Fixes
v1.52.0
Compare Source
Features
kulshekhar/ts-jest (ts-jest)
v29.1.4
Compare Source
Bug Fixes
Features
type: "module"
(#4210) (81a5f64), closes #4210 #4012v29.1.3
Compare Source
Bug Fixes
@jest/transform
as an optional peer dependency (0ba7f86)Performance Improvements
Configuration
📅 Schedule: Branch creation - "before 4am on the first day of the month" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by Mend Renovate. View repository job log here.