chore(deps): update all non-major dependencies

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@sxzz/eslint-config-prettier	^2.1.0 -> ^2.2.2
@sxzz/eslint-config-ts	^2.1.0 -> ^2.2.2
commander	^9.1.0 -> ^9.3.0
cos-nodejs-sdk-v5	^2.11.6 -> ^2.11.9
esbuild	^0.14.34 -> ^0.14.42
eslint (source)	^8.13.0 -> ^8.16.0
eslint-define-config	^1.3.0 -> ^1.4.1
esno	^0.14.1 -> ^0.16.3
got	^12.0.3 -> ^12.1.0
tsup	^5.12.4 -> ^5.12.9
typescript (source)	^4.6.3 -> ^4.7.2

---

Release Notes

sxzz/eslint-config

v2.2.2

Compare Source

v2.2.1

Compare Source

v2.2.0

Compare Source

Features

• move package.json field order (b7f16b8)

Bug Fixes

• deps: update all non-major dependencies (#​26) (96ede34)

2.1.1 (2022-04-13)

Bug Fixes

• cjs require (c3fd51f)
• deps: update all non-major dependencies (#​24) (612dbd5)
• deps: update dependency eslint-plugin-unicorn to v42 (#​25) (fb89407)
• disable import rule (b4992c2)

v2.1.1

Compare Source

tj/commander.js

v9.3.0

Compare Source

Added

• .summary() for a short summary to use instead of description when listing subcommands in help ([#​1726])
• Option.implies() to set other option values when the option is specified ([#​1724])
• updated Chinese README with 9.x changes ([#​1727])

Fixed

• TypeScript: add string[] to .options() default value parameter type for use with variadic options ([#​1721])

Deprecated

• multi-character short option flag (e.g. -ws) ([#​1718])

v9.2.0

Compare Source

Added

• conditional export of 'types' for upcoming TypeScript module resolution ([#​1703])
• example file showing two ways to add global options to subcommands ([#​1708])

Fixed

• detect option conflicts in parent commands of called subcommand ([#​1710])

Changed

• replace deprecated String.prototype.substr ([#​1706])

tencentyun/cos-nodejs-sdk-v5

v2.11.9

Compare Source

v2.11.8

Compare Source

fix：优化getObjectUrl支持全球加速参数

Merged

• Feat/get object support use accelerate #145

Commits

• Updated CHANGELOG.md 213f98b
• update version 2.11.8 3c55477

v2.11.7

Compare Source

feat：getObjectUrl支持全球加速参数

fix：请求返回错误类型兼容处理

Merged

• fix：兼容错误类型 #144
• feat：补充d.ts;支持设置host不参与签名； #143
• fix: 修复错误的将开发环境依赖添加到正式依赖中 #138
• fix: 移除多于的模块引入 #129

Commits

• Updated CHANGELOG.md d0f283e
• upd d.ts b5b59f1

evanw/esbuild

v0.14.42

Compare Source

• Fix a parser hang on invalid CSS (#​2276)

  Previously invalid CSS with unbalanced parentheses could cause esbuild's CSS parser to hang. An example of such an input is the CSS file :x(. This hang has been fixed.

• Add support for custom log message levels

  This release allows you to override the default log level of esbuild's individual log messages. For example, CSS syntax errors are treated as warnings instead of errors by default because CSS grammar allows for rules containing syntax errors to be ignored. However, if you would like for esbuild to consider CSS syntax errors to be build errors, you can now configure that like this:

  • CLI

    $ esbuild example.css --log-override:css-syntax-error=error

  • JS API

    let result = await esbuild.build({
      entryPoints: ['example.css'],
      logOverride: {
        'css-syntax-error': 'error',
      },
    })

  • Go API

    result := api.Build(api.BuildOptions{
      EntryPoints: []string{"example.ts"},
      LogOverride: map[string]api.LogLevel{
        "css-syntax-error": api.LogLevelError,
      },
    })

  You can also now use this feature to silence warnings that you are not interested in. Log messages are referred to by their identifier. Each identifier is stable (i.e. shouldn't change over time) except there is no guarantee that the log message will continue to exist. A given log message may potentially be removed in the future, in which case esbuild will ignore log levels set for that identifier. The current list of supported log level identifiers for use with this feature can be found below:

  JavaScript:

  • assign-to-constant
  • call-import-namespace
  • commonjs-variable-in-esm
  • delete-super-property
  • direct-eval
  • duplicate-case
  • duplicate-object-key
  • empty-import-meta
  • equals-nan
  • equals-negative-zero
  • equals-new-object
  • html-comment-in-js
  • impossible-typeof
  • private-name-will-throw
  • semicolon-after-return
  • suspicious-boolean-not
  • this-is-undefined-in-esm
  • unsupported-dynamic-import
  • unsupported-jsx-comment
  • unsupported-regexp
  • unsupported-require-call

  CSS:

  • css-syntax-error
  • invalid-@​charset
  • invalid-@​import
  • invalid-@​nest
  • invalid-@​layer
  • invalid-calc
  • js-comment-in-css
  • unsupported-@​charset
  • unsupported-@​namespace
  • unsupported-css-property

  Bundler:

  • different-path-case
  • ignored-bare-import
  • ignored-dynamic-import
  • import-is-undefined
  • package.json
  • require-resolve-not-external
  • tsconfig.json

  Source maps:

  • invalid-source-mappings
  • sections-in-source-map
  • missing-source-map
  • unsupported-source-map-comment

  Documentation about which identifiers correspond to which log messages will be added in the future, but hasn't been written yet. Note that it's not possible to configure the log level for a build error. This is by design because changing that would cause esbuild to incorrectly proceed in the building process generate invalid build output. You can only configure the log level for non-error log messages (although you can turn non-errors into errors).

v0.14.41

Compare Source

• Fix a minification regression in 0.14.40 (#​2270, #​2271, #​2273)

  Version 0.14.40 substituted string property keys with numeric property keys if the number has the same string representation as the original string. This was done in three places: computed member expressions, object literal properties, and class fields. However, negative numbers are only valid in computed member expressions while esbuild incorrectly applied this substitution for negative numbers in all places. This release fixes the regression by only doing this substitution for negative numbers in computed member expressions.

  This fix was contributed by @​susiwen8.

v0.14.40

Compare Source

• Correct esbuild's implementation of "preserveValueImports": true (#​2268)

  TypeScript's preserveValueImports setting tells the compiler to preserve unused imports, which can sometimes be necessary because otherwise TypeScript will remove unused imports as it assumes they are type annotations. This setting is useful for programming environments that strip TypeScript types as part of a larger code transformation where additional code is appended later that will then make use of those unused imports, such as with Svelte or Vue.

  This release fixes an issue where esbuild's implementation of preserveValueImports diverged from the official TypeScript compiler. If the import clause is present but empty of values (even if it contains types), then the import clause should be considered a type-only import clause. This was an oversight, and has now been fixed:

  // Original code
  import "keep"
  import { k1 } from "keep"
  import k2, { type t1 } from "keep"
  import {} from "remove"
  import { type t2 } from "remove"
  
  // Old output under "preserveValueImports": true
  import "keep";
  import { k1 } from "keep";
  import k2, {} from "keep";
  import {} from "remove";
  import {} from "remove";
  
  // New output under "preserveValueImports": true (matches the TypeScript compiler)
  import "keep";
  import { k1 } from "keep";
  import k2 from "keep";

• Avoid regular expression syntax errors in older browsers (#​2215)

  Previously esbuild always passed JavaScript regular expression literals through unmodified from the input to the output. This is undesirable when the regular expression uses newer features that the configured target environment doesn't support. For example, the d flag (i.e. the match indices feature) is new in ES2022 and doesn't work in older browsers. If esbuild generated a regular expression literal containing the d flag, then older browsers would consider esbuild's output to be a syntax error and none of the code would run.

  With this release, esbuild now detects when an unsupported feature is being used and converts the regular expression literal into a new RegExp() constructor instead. One consequence of this is that the syntax error is transformed into a run-time error, which allows the output code to run (and to potentially handle the run-time error). Another consequence of this is that it allows you to include a polyfill that overwrites the RegExp constructor in older browsers with one that supports modern features. Note that esbuild does not handle polyfills for you, so you will need to include a RegExp polyfill yourself if you want one.

  // Original code
  console.log(/b/d.exec('abc').indices)
  
  // New output (with --target=chrome90)
  console.log(/b/d.exec("abc").indices);
  
  // New output (with --target=chrome89)
  console.log(new RegExp("b", "d").exec("abc").indices);

  This is currently done transparently without a warning. If you would like to debug this transformation to see where in your code esbuild is transforming regular expression literals and why, you can pass --log-level=debug to esbuild and review the information present in esbuild's debug logs.

• Add Opera to more internal feature compatibility tables (#​2247, #​2252)

  The internal compatibility tables that esbuild uses to determine which environments support which features are derived from multiple sources. Most of it is automatically derived from these ECMAScript compatibility tables, but missing information is manually copied from MDN, GitHub PR comments, and various other websites. Version 0.14.35 of esbuild introduced Opera as a possible target environment which was automatically picked up by the compatibility table script, but the manually-copied information wasn't updated to include Opera. This release fixes this omission so Opera feature compatibility should now be accurate.

  This was contributed by @​lbwa.

• Ignore EPERM errors on directories (#​2261)

  Previously bundling with esbuild when inside a sandbox environment which does not have permission to access the parent directory did not work because esbuild would try to read the directory to search for a node_modules folder and would then fail the build when that failed. In practice this caused issues with running esbuild with sandbox-exec on macOS. With this release, esbuild will treat directories with permission failures as empty to allow for the node_modules search to continue past the denied directory and into its parent directory. This means it should now be possible to bundle with esbuild in these situations. This fix is similar to the fix in version 0.9.1 but is for EPERM while that fix was for EACCES.

• Remove an irrelevant extra "use strict" directive (#​2264)

  The presence of a "use strict" directive in the output file is controlled by the presence of one in the entry point. However, there was a bug that would include one twice if the output format is ESM. This bug has been fixed.

• Minify strings into integers inside computed properties (#​2214)

  This release now minifies a["0"] into a[0] when the result is equivalent:

  // Original code
  console.log(x['0'], { '0': x }, class { '0' = x })
  
  // Old output (with --minify)
  console.log(x["0"],{"0":x},class{"0"=x});
  
  // New output (with --minify)
  console.log(x[0],{0:x},class{0=x});

  This transformation currently only happens when the numeric property represents an integer within the signed 32-bit integer range.

v0.14.39

Compare Source

• Fix code generation for export default and /* @​__PURE__ */ call (#​2203)

  The /* @​__PURE__ */ comment annotation can be added to function calls to indicate that they are side-effect free. These annotations are passed through into the output by esbuild since many JavaScript tools understand them. However, there was an edge case where printing this comment before a function call caused esbuild to fail to parenthesize a function literal because it thought it was no longer at the start of the expression. This problem has been fixed:

  // Original code
  export default /* @​__PURE__ */ (function() {
  })()
  
  // Old output
  export default /* @​__PURE__ */ function() {
  }();
  
  // New output
  export default /* @​__PURE__ */ (function() {
  })();

• Preserve ... before JSX child expressions (#​2245)

  TypeScript 4.5 changed how JSX child expressions that start with ... are emitted. Previously the ... was omitted but starting with TypeScript 4.5, the ... is now preserved instead. This release updates esbuild to match TypeScript's new output in this case:

  // Original code
  console.log(<a>{...b}</a>)
  
  // Old output
  console.log(/* @&#8203;__PURE__ */ React.createElement("a", null, b));
  
  // New output
  console.log(/* @&#8203;__PURE__ */ React.createElement("a", null, ...b));

  Note that this behavior is TypeScript-specific. Babel doesn't support the ... token at all (it gives the error "Spread children are not supported in React").

• Slightly adjust esbuild's handling of the browser field in package.json (#​2239)

  This release changes esbuild's interpretation of browser path remapping to fix a regression that was introduced in esbuild version 0.14.21. Browserify has a bug where it incorrectly matches package paths to relative paths in the browser field, and esbuild replicates this bug for compatibility with Browserify. I have a set of tests that I use to verify that esbuild's replication of this Browserify is accurate here: https://github.com/evanw/package-json-browser-tests. However, I was missing a test case and esbuild's behavior diverges from Browserify in this case. This release now handles this edge case as well:

  • entry.js:

    require('pkg/sub')

  • node_modules/pkg/package.json:

    {
      "browser": {
        "./sub": "./sub/foo.js",
        "./sub/sub.js": "./sub/foo.js"
      }
    }

  • node_modules/pkg/sub/foo.js:

    require('sub')

  • node_modules/sub/index.js:

    console.log('works')

  The import path sub in require('sub') was previously matching the remapping "./sub/sub.js": "./sub/foo.js" but with this release it should now no longer match that remapping. Now require('sub') will only match the remapping "./sub/sub": "./sub/foo.js" (without the trailing .js). Browserify apparently only matches without the .js suffix here.

v0.14.38

Compare Source

• Further fixes to TypeScript 4.7 instantiation expression parsing (#​2201)

  This release fixes some additional edge cases with parsing instantiation expressions from the upcoming version 4.7 of TypeScript. Previously it was allowed for an instantiation expression to precede a binary operator but with this release, that's no longer allowed. This was sometimes valid in the TypeScript 4.7 beta but is no longer allowed in the latest version of TypeScript 4.7. Fixing this also fixed a regression that was introduced by the previous release of esbuild:

  Code	TS 4.6.3	TS 4.7.0 beta	TS 4.7.0 nightly	esbuild 0.14.36	esbuild 0.14.37	esbuild 0.14.38
  a<b> == c<d>	Invalid	a == c	Invalid	a == c	a == c	Invalid
  a<b> in c<d>	Invalid	Invalid	Invalid	Invalid	a in c	Invalid
  a<b>>=c<d>	Invalid	Invalid	Invalid	Invalid	a >= c	Invalid
  a<b>=c<d>	Invalid	a < b >= c	a = c	a < b >= c	a = c	a = c
  a<b>>c<d>	a < b >> c	a < b >> c	a < b >> c	a < b >> c	a > c	a < b >> c

  This table illustrates some of the more significant changes between all of these parsers. The most important part is that esbuild 0.14.38 now matches the behavior of the latest TypeScript compiler for all of these cases.

v0.14.37

Compare Source

• Add support for TypeScript's moduleSuffixes field from TypeScript 4.7

  The upcoming version of TypeScript adds the moduleSuffixes field to tsconfig.json that introduces more rules to import path resolution. Setting moduleSuffixes to [".ios", ".native", ""] will try to look at the the relative files ./foo.ios.ts, ./foo.native.ts, and finally ./foo.ts for an import path of ./foo. Note that the empty string "" in moduleSuffixes is necessary for TypeScript to also look-up ./foo.ts. This was announced in the TypeScript 4.7 beta blog post.

• Match the new ASI behavior from TypeScript nightly builds (#​2188)

  This release updates esbuild to match some very recent behavior changes in the TypeScript parser regarding automatic semicolon insertion. For more information, see TypeScript issues #​48711 and #​48654 (I'm not linking to them directly to avoid Dependabot linkback spam on these issues due to esbuild's popularity). The result is that the following TypeScript code is now considered valid TypeScript syntax:

  class A<T> {}
  new A<number> /* ASI now happens here */
  if (0) {}
  
  interface B {
    (a: number): typeof a /* ASI now happens here */
    <T>(): void
  }

  This fix was contributed by @​g-plane.

v0.14.36

Compare Source

• Revert path metadata validation for now (#​2177)

  This release reverts the path metadata validation that was introduced in the previous release. This validation has uncovered a potential issue with how esbuild handles onResolve callbacks in plugins that will need to be fixed before path metadata validation is re-enabled.

v0.14.35

Compare Source

• Add support for parsing typeof on #private fields from TypeScript 4.7 (#​2174)

  The upcoming version of TypeScript now lets you use #private fields in typeof type expressions:

  https://devblogs.microsoft.com/typescript/announcing-typescript-4-7-beta/#typeof-on-private-fields

  class Container {
    #data = "hello!";
  
    get data(): typeof this.#data {
      return this.#data;
    }
  
    set data(value: typeof this.#data) {
      this.#data = value;
    }
  }

  With this release, esbuild can now parse these new type expressions as well. This feature was contributed by @​magic-akari.

• Add Opera and IE to internal CSS feature support matrix (#​2170)

  Version 0.14.18 of esbuild added Opera and IE as available target environments, and added them to the internal JS feature support matrix. CSS feature support was overlooked, however. This release adds knowledge of Opera and IE to esbuild's internal CSS feature support matrix:

  /* Original input */
  a {
    color: rgba(0, 0, 0, 0.5);
  }
  
  /* Old output (with --target=opera49 --minify) */
  a{color:rgba(0,0,0,.5)}
  
  /* New output (with --target=opera49 --minify) */
  a{color:#​00000080}

  The fix for this issue was contributed by @​sapphi-red.

• Change TypeScript class field behavior when targeting ES2022

  TypeScript 4.3 introduced a breaking change where class field behavior changes from assign semantics to define semantics when the target setting in tsconfig.json is set to ESNext. Specifically, the default value for TypeScript's useDefineForClassFields setting when unspecified is true if and only if target is ESNext. TypeScript 4.6 introduced another change where this behavior now happens for both ESNext and ES2022. Presumably this will be the case for ES2023 and up as well. With this release, esbuild's behavior has also been changed to match. Now configuring esbuild with --target=es2022 will also cause TypeScript files to use the new class field behavior.

• Validate that path metadata returned by plugins is consistent

  The plugin API assumes that all metadata for the same path returned by a plugin's onResolve callback is consistent. Previously this assumption was just assumed without any enforcement. Starting with this release, esbuild will now enforce this by generating a build error if this assumption is violated. The lack of validation has not been an issue (I have never heard of this being a problem), but it still seems like a good idea to enforce it. Here's a simple example of a plugin that generates inconsistent sideEffects metadata:

  let buggyPlugin = {
    name: 'buggy',
    setup(build) {
      let count = 0
      build.onResolve({ filter: /^react$/ }, args => {
        return {
          path: require.resolve(args.path),
          sideEffects: count++ > 0,
        }
      })
    },
  }

  Since esbuild processes everything in parallel, the set of metadata that ends up being used for a given path is essentially random since it's whatever the task scheduler decides to schedule first. Thus if a plugin does not consistently provide the same metadata for a given path, subsequent builds may return different results. This new validation check prevents this problem.

  Here's the new error message that's shown when this happens:

  ✘ [ERROR] [plugin buggy] Detected inconsistent metadata for the path "node_modules/react/index.js" when it was imported here:
  
      button.tsx:1:30:
        1 │ import { createElement } from 'react'
          ╵                               ~~~~~~~
  
    The original metadata for that path comes from when it was imported here:
  
      app.tsx:1:23:
        1 │ import * as React from 'react'
          ╵                        ~~~~~~~
  
    The difference in metadata is displayed below:
  
     {
    -  "sideEffects": true,
    +  "sideEffects": false,
     }
  
    This is a bug in the "buggy" plugin. Plugins provide metadata for a given path in an "onResolve"
    callback. All metadata provided for the same path must be consistent to ensure deterministic
    builds. Due to parallelism, one set of provided metadata will be randomly chosen for a given path,
    so providing inconsistent metadata for the same path can cause non-determinism.
  

• Suggest enabling a missing condition when exports map fails (#​2163)

  This release adds another suggestion to the error message that happens when an exports map lookup fails if the failure could potentially be fixed by adding a missing condition. Here's what the new error message looks like (which now suggests --conditions=module as a possible workaround):

  ✘ [ERROR] Could not resolve "@​sentry/electron/main"
  
      index.js:1:24:
        1 │ import * as Sentry from '@​sentry/electron/main'
          ╵                         ~~~~~~~~~~~~~~~~~~~~~~~
  
    The path "./main" is not currently exported by package "@​sentry/electron":
  
      node_modules/@​sentry/electron/package.json:8:13:
        8 │   "exports": {
          ╵              ^
  
    None of the conditions provided ("require", "module") match any of the currently active conditions
    ("browser", "default", "import"):
  
      node_modules/@​sentry/electron/package.json:16:14:
        16 │     "./main": {
           ╵               ^
  
    Consider enabling the "module" condition if this package expects it to be enabled. You can use
    "--conditions=module" to do that:
  
      node_modules/@​sentry/electron/package.json:18:6:
        18 │       "module": "./esm/main/index.js"
           ╵       ~~~~~~~~
  
    Consider using a "require()" call to import this file, which will work because the "require"
    condition is supported by this package:
  
      index.js:1:24:
        1 │ import * as Sentry from '@​sentry/electron/main'
          ╵                         ~~~~~~~~~~~~~~~~~~~~~~~
  
    You can mark the path "@​sentry/electron/main" as external to exclude it from the bundle, which
    will remove this error.
  

  This particular package had an issue where it was using the Webpack-specific module condition without providing a default condition. It looks like the intent in this case was to use the standard import condition instead. This specific change wasn't suggested here because this error message is for package consumers, not package authors.

eslint/eslint

v8.16.0

Compare Source

Features

• cab0c22 feat: add Unicode flag suggestion in no-misleading-character-class (#​15867) (Milos Djermanovic)
• 38ae956 feat: check Unicode code point escapes in no-control-regex (#​15862) (Milos Djermanovic)
• ee69cd3 feat: Update global variables (#​15871) (Sébastien Règne)

Bug Fixes

• 3f09aab fix: function-paren-newline crash on "new new Foo();" (#​15850) (coderaiser)

Documentation

• 050d5f4 docs: Static further reading links (#​15890) (Nicholas C. Zakas)
• 36287c0 docs: fix absolute paths in related rules shortcode to work from /docs (#​15892) (Milos Djermanovic)
• 90b6990 docs: fix absolute links in rule macro to work from /docs (#​15891) (Milos Djermanovic)
• f437249 docs: Adjust docs site path prefix (#​15889) (Nicholas C. Zakas)
• 6e16025 docs: update 'Related Rules' and 'Further Reading' in remaining rules (#​15884) (Milos Djermanovic)
• 1d39f69 docs: remove confusing examples for no-mixed-operators (#​15875) (Milos Djermanovic)
• 3071d76 docs: Fix some grammar issues (#​15837) (byodian)

Chores

• 1768d0d chore: upgrade @​eslint/eslintrc@​1.3.0 (#​15903) (Milos Djermanovic)
• c686e4c chore: Add deploy workflow for docs site (#​15894) (Nicholas C. Zakas)
• c7894cd chore: enable some rules from eslint-plugin-unicorn internally (#​15878) (Bryan Mishkin)
• ea65cb5 chore: upgrade eslint-plugin-eslint-plugin@^4.2.0 (#​15882) (唯然)
• cc29c69 chore: Upgrade official GitHub actions to latest versions (#​15880) (Darius Dzien)
• 5891c75 chore: Refactor rule docs format (#​15869) (Nicholas C. Zakas)

v8.15.0

Compare Source

Features

• ab37d3b feat: add enforceInClassFields option to no-underscore-dangle (#​15818) (Roberto Cestari)

Bug Fixes

• 8bf9440 fix: "use strict" should not trigger strict mode in ES3 (#​15846) (Milos Djermanovic)

Documentation

• 28116cc docs: update AST node names link in no-restricted-syntax (#​15843) (Milos Djermanovic)
• 272965f docs: fix h1 heading on formatters page (#​15834) (Milos Djermanovic)
• a798166 docs: update example for running individual rule tests (#​15833) (Milos Djermanovic)
• 57e732b docs: mark SourceCode#getJSDocComment deprecated in working-with-rules (#​15829) (Milos Djermanovic)
• 9a90abf docs: update docs directory in working-with-rules (#​15830) (Milos Djermanovic)
• 810adda docs: add more examples for prefer-object-spread (#​15831) (coderaiser)
• 06b1edb docs: clarify no-control-regex rule (#​15808) (Milos Djermanovic)
• 9ecd42f docs: Fixed typo in code comment (#​15812) (Addison G)
• de992b7 docs: remove links to 2fa document (#​15804) (Milos Djermanovic)
• 5222659 docs: fix 'Related Rules' heading in no-constant-binary-expression (#​15799) (Milos Djermanovic)
• e70ae81 docs: Update README team and sponsors (ESLint Jenkins)

Chores

• 1ba6a92 chore: upgrade @​eslint/eslintrc@​1.2.3 (#​15847) (Milos Djermanovic)
• 8167aa7 chore: bump version of minimatch due to security issue PRISMA-2022-0039 (#​15774) (Jan Opravil)
• b8995a4 chore: Implement docs site (#​15815) (Nicholas C. Zakas)
• 6494e3e chore: update link in codeql-analysis.yml (#​15817) (Milos Djermanovic)
• 36503ec chore: enable no-constant-binary-expression in eslint-config-eslint (#​15807) (唯然)

v8.14.0

Compare Source

Features

• ab6363d feat: Add rule no-constant-binary-expression (#​15296) (Jordan Eldredge)

Bug Fixes

• 35fa1dd fix: allow project paths to have URL-encoded characters (#​15795) (Milos Djermanovic)
• 413f1d5 fix: update astUtils.isDirectiveComment with globals and exported (#​15775) (Milos Djermanovic)

Build Related

• c2407e8 build: add node v18 (#​15791) (唯然)

Chores

• 735458c chore: add static frontmatter to no-constant-binary-expression docs (#​15798) (Milos Djermanovic)
• db28f2c chore: Add static frontmatter to docs (#​15782) (Nicholas C. Zakas)
• 3bca59e chore: markdownlint autofix on commit (#​15783) (Nicholas C. Zakas)

Shinigami92/eslint-define-config

v1.4.1

Compare Source

diff

• Update rules for: [eslint, typescript-eslint, vue]

v1.4.0

Compare Source

diff

• Generate rules for: [vue-pug]
• Removed rules for: [vue-pug-sfc]
• Update ParserOptions
• Update rules for: [eslint, import, jsdoc, typescript-eslint, unicorn, vue]

antfu/esno

v0.16.3

Compare Source

v0.16.2

Compare Source

v0.16.1

Compare Source

v0.15.0

Compare Source

sindresorhus/got

v12.1.0

Compare Source

Improvements

• Add response.ok (#​2043) 22d58fb
  • This is only useful if you have {throwHttpErrors: false}

Fixes

• Do not redirect to UNIX sockets (#​2047) 861ccd9

v12.0.4

Compare Source

• Remove stream lock - unreliable since Node 17.3.0 bb8eca9

egoist/tsup

v5.12.9

Compare Source

Bug Fixes

• deps: Update rollup and rollup-plugin-dts to latest versions (#​632) (a792668)

Features

• minor: allow tsup config function to be asynchronous (#​627) (ad2629a)

v5.12.8

Compare Source

Bug Fixes

• update source-map to 0.8.0-beta.0, closes #​623 (c67e03d)

v5.12.7

Compare Source

Bug Fixes

• define a build-time constant called TSUP_FORMAT (f4a56ed)
• resolve to package.json only if tsup key exists (#​622) (67eea53)

v5.12.6

Compare Source

Bug Fixes

• dts: use relative baseUrl in tsconfig, closes #​611 (df40e12)

v5.12.5

Compare Source

Bug Fixes

• Exit Code returns 0 for failed builds, closes #​606 (b3ad95f)

Microsoft/TypeScript

v4.7.2

Compare Source

For release notes, check out the release announcement.

For the complete list of fixed issues, check out the

• fixed issues query for Typescript 4.7.0 (Beta).
• fixed issues query for Typescript 4.7.1 (RC).
• fixed issues query for Typescript 4.7.2 (Stable).

Downloads are available on:

• npm
• Visual Studio 2022/2019 (Select new version in project options)
• NuGet package

v4.6.4

Compare Source

This release includes a bug fix for text formatting on certain ranges, which was impacting Visual Studio users.

For the complete list of fixed issues, check out the

• fixed issues query for Typescript 4.6.0 (Beta).
• fixed issues query for Typescript 4.6.1 (RC).
• fixed issues query for Typescript 4.6.2 (Stable).
• fixed issues query for Typescript 4.6.3 (Stable).
• fixed issues query for Typescript 4.6.4 (Stable).

Downloads are available on:

• npm
• Visual Studio 2022/2019 (Select new version in project options)
• NuGet package

---

Configuration

📅 Schedule: "before 3am on Monday" (UTC).

🚦 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.

---

• If you want to rebase/retry this PR, click this checkbox.

---

This PR has been generated by Mend Renovate. View repository job log here.