ernie-research/MEnvBench huggingface dataset:
Repository: style-dictionary/style-dictionary (JavaScript)

Issue:
Does not output reference when values is zero
When using `outputReference`, if the referenced alias has a value of zero it being ignored and the reference is not being replaced.

Input to recreate the issue:
```code
// json
{
  "Offset": {
    "value": "0",
    "type": "other"
  },
  "Spacing": {
    "value": "2 + {Offset}",
    "type": "spacing"
  }
}
```
Actual result
```code
// css
--offset: 0;
--spacing: 2 + 0;
```

Expected result
```code
// css
--offset: 0;
--spacing: 2 + var(--offset);
```

After a quick look, it seems the issue is here, the condition is checking for a truthy value and zero is falsy: https://github.com/amzn/style-dictionary/blob/2cf72f3f89996503608c238d7f3bcbab5b53e719/lib/common/formatHelpers/createPropertyFormatter.js#LL114C21-L114C21

And I think this issue is related #886 


Discussion: Like [here](https://github.com/amzn/style-dictionary/issues/988) you can use function in `filter`

```
        function(token) {
            // omit empty or zero tokens
            if (token.value !=0) {
              return token
            }
```
I have reproduced this bug. There have been some fixes to outputReferences in `v3.9.0` and planning to forward port those to `v4.0.0-prerelease.1` which solve the following:
```json
{
  "Offset": {
    "value": "0",
    "type": "other"
  },
  "Spacing": {
    "value": "2 + {Offset}",
    "type": "spacing"
  }
}
```

But when you mentioned the truthy check, I realized there is another bug indeed that is not fixed, which can be reproduced by making the "0" in your JSON a number rather than string:

```json
{
  "Offset": {
    "value": 0,
    "type": "other"
  },
  "Spacing": {
    "value": "2 + {Offset}",
    "type": "spacing"
  }
}
```



Fix (patch):
diff --git a/lib/common/formatHelpers/createPropertyFormatter.js b/lib/common/formatHelpers/createPropertyFormatter.js
index 2e28ea718..e41eaad94 100644
--- a/lib/common/formatHelpers/createPropertyFormatter.js
+++ b/lib/common/formatHelpers/createPropertyFormatter.js
@@ -184,7 +184,10 @@ function createPropertyFormatter({
         // because Style Dictionary resolved this in the resolution step.
         // Here we are undoing that by replacing the value with
         // the reference's name
-        if (ref.value && ref.name) {
+
+        // Safe way to check if object contains a property.
+        // below can be replaced with the new safe Object.hasOwn() in evergreen browsers / Node 16.9.0 onwards
+        if (Object.prototype.hasOwnProperty.call(ref, 'value') && Object.prototype.hasOwnProperty.call(ref, 'name')) {
           const replaceFunc = function() {
             if (format === 'css') {
               if (outputReferenceFallbacks) {
Repository: style-dictionary/style-dictionary (JavaScript)

Issue:
Unexpected collision log
As discussed in #1308, the following two files:

```
// colors-1.json
{
  "colors": {
    "$type": "color",
    "black": { "$value": "#000000" }
  }
}
```

```
// colors-2.json
{
  "colors": {
    "$type": "color",
    "white": { "$value": "#ffffff" }
  }
}
```
Result in the following console log despite the tokens being generated correctly:

> Token collisions detected (1):
> 
> Collision detected at: colors! Original value: color, New value: color

This can be demonstrated in this [minimally reproducible example](https://stackblitz.com/edit/style-dictionary-merging?file=package.json).

Removing `"$type": "color"` from one or both of the files resolves the collision logging issue.


Discussion: Confirmed bug: https://github.com/amzn/style-dictionary/blob/main/lib/utils/deepExtend.js#L93 here somewhere



Fix (patch):
diff --git a/.changeset/short-garlics-search.md b/.changeset/short-garlics-search.md
new file mode 100644
index 000000000..c63f2e769
--- /dev/null
+++ b/.changeset/short-garlics-search.md
@@ -0,0 +1,5 @@
+---
+'style-dictionary': patch
+---
+
+Fix an issue with token collisions being way to eager about complaining when values that are identical are "colliding". This cuts collision warnings by 75% or more.
diff --git a/__integration__/tokens/size/_padding.json b/__integration__/tokens/size/_padding.json
index f000f8c17..017c3e948 100644
--- a/__integration__/tokens/size/_padding.json
+++ b/__integration__/tokens/size/_padding.json
@@ -1,10 +1,10 @@
 {
   "size": {
     "padding": {
-      "small": { "value": 0.5, "type": "dimension" },
-      "medium": { "value": 1, "type": "dimension" },
-      "large": { "value": 1, "type": "dimension" },
-      "xl": { "value": 1, "type": "dimension" }
+      "small": { "value": 0.6, "type": "dimension" },
+      "medium": { "value": 1.1, "type": "dimension" },
+      "large": { "value": 1.1, "type": "dimension" },
+      "xl": { "value": 1.1, "type": "dimension" }
     }
   }
 }
diff --git a/lib/utils/deepExtend.js b/lib/utils/deepExtend.js
index 4067c2b64..b979ee819 100644
--- a/lib/utils/deepExtend.js
+++ b/lib/utils/deepExtend.js
@@ -89,7 +89,8 @@ export default function deepExtend(objects, opts = {}, path) {
           // Don't bring in undefined values
         } else if (copy !== undefined) {
           if (src != null) {
-            if (typeof collision == 'function') {
+            // if src & copy are the exact same value, then the collision doesn't matter
+            if (typeof collision === 'function' && src !== copy) {
               collision({ target, copy: options, path, key: name });
             }
Repository: playcanvas/engine (JavaScript)

Issue:
When updating the raw `data` of a template asset, the associated template does not get updated
### Issue

In the Editor, template assets get updated, when the user applies an override on them. The underlying raw `data` gets updated here:

https://github.com/playcanvas/engine/blob/2d32970cbc83dcc6e0aefcc77956d5fd547bcd26/src/framework/asset/asset.js#L361-L373

But the actual `resource`, which corresponds to a `Template`, does not get touched, so we are working with a stale version of the template within the editor.

Example:

```js
const first = asset.resource.instantiate();
asset.data = data2;
const second = asset.resource.instantiate();
// second has the same structure as first
```



Fix (patch):
diff --git a/src/framework/handlers/template.js b/src/framework/handlers/template.js
index c580999d45e..c4f915f95da 100644
--- a/src/framework/handlers/template.js
+++ b/src/framework/handlers/template.js
@@ -52,6 +52,18 @@ class TemplateHandler extends ResourceHandler {
         this.decoder ??= new TextDecoder('utf-8');
         return new Template(this._app, JSON.parse(this.decoder.decode(data)));
     }
+
+    patch(asset, registry) {
+        // only process if this looks like valid template data
+        if (!asset || !asset.resource || !asset.data || !asset.data.entities) {
+            return;
+        }
+
+        const template = asset.resource;
+
+        // the `data` setter will handle cache invalidation
+        template.data = asset.data;
+    }
 }
 
 export { TemplateHandler };
diff --git a/src/framework/template.js b/src/framework/template.js
index 4af2ef95d4a..b3493ce157a 100644
--- a/src/framework/template.js
+++ b/src/framework/template.js
@@ -54,6 +54,16 @@ class Template {
 
         this._templateRoot = parser.parse(this._data);
     }
+
+    set data(value) {
+        this._data = value;
+        // cache invalidation: the next instantiate() will parse and use the new _data
+        this._templateRoot = null;
+    }
+
+    get data() {
+        return this._data;
+    }
 }
 
 export { Template };
Repository: clientIO/joint (JavaScript)

Issue:
[Bug]: RegEx for breakText and textWrap opt.hyphen does not include international characters
### What happened?

By default breakText and textWrap do not include chraracters from international alphabets leading to strange behaviour when wrapping words containing them. In my opinion the default should include those.

Suggested regex to match them:
`/[^\w\dŽžÀ-ÿ]/`

### Version

3.7.5

### What browsers are you seeing the problem on?

any browser

### What operating system are you seeing the problem on?

any OS


Discussion: This might work better `/[^\w\d\u00C0-\u1FFF\u2800-\uFFFD]/` (from [StackOverflow answer](https://stackoverflow.com/a/59828814/2921495)).

The one you provided doesn't work for Czech `ř`, for example.

Note, this should not be a blocker as you can provide a custom `hyphen` to the `textWrap` attribute.



Fix (patch):
diff --git a/src/util/util.mjs b/src/util/util.mjs
index 57d08f1a0..fe369310a 100644
--- a/src/util/util.mjs
+++ b/src/util/util.mjs
@@ -631,7 +631,7 @@ export const breakText = function(text, size, styles = {}, opt = {}) {
     // If separator is a RegExp, we use the space character to join words together again (not ideal)
     const separatorChar = (typeof separator === 'string') ? separator : space;
     var eol = opt.eol || '\n';
-    var hyphen = opt.hyphen ? new RegExp(opt.hyphen) : /[^\w\d]/;
+    var hyphen = opt.hyphen ? new RegExp(opt.hyphen) : /[^\w\d\u00C0-\u1FFF\u2800-\uFFFD]/;
     var maxLineCount = opt.maxLineCount;
     if (!isNumber(maxLineCount)) maxLineCount = Infinity;
Repository: clientIO/joint (JavaScript)

Issue:
[Bug]: Changing link target or source breaks CommandManager in Angular
### Current versus expected behaviour

When running the kitchensink application in Angular 16, changing the target or source of a link breaks the CommandManager. The change itself and any changes made after that action are no longer put on the undo stack. No error is shown in the browser console.

This bug occurs in both JointJS+ 4.0.0 and 4.0.1, but only in the Angular kitchensink app and not it the plain JS one. It does not occur in the previous 3.7.3 version.

Other changes to links to not cause this problem, vertices for example can be added, moved and removed and the CommandManager works just fine.

We have an application based on both Angular and JointJS+ and we encountered the same problem there.

### Steps to reproduce

1. Launch kitchensink application in Angular 16, either on JointJS+ 4.0.0 or 4.0.1.
2. Move some elements around to fill the undo stack.
3. Change the target or source of a link.
4. Click the "Undo" button
5. Not the change to the link but the change before that is reverted.
6. Any other changes made to the graph are also no longer being put on the command manager stack after that.

### Version

4.0.1

### What browsers are you seeing the problem on?

Firefox, Chrome

### What operating system are you seeing the problem on?

Linux


Discussion: We can reproduce the issue.

Here's a workaround for the time being:
```ts
this.paper.on('link:connect', () => {
    this.commandManager.storeBatchCommand()
});
```
Here's a proper patch that you need to apply locally until we release a new version.

```ts
  joint.dia.CellView.prototype.pointerup = function(evt, x, y) {

      const { graph = this.model.graph } = this.eventData(evt);

      this.notify('cell:pointerup', evt, x, y);

      if (graph) {
          // we don't want to trigger event on model as model doesn't
          // need to be member of collection anymore (remove)
          graph.stopBatch('pointer', { cell: this.model });
      }
  }
```

It's a regression caused by this [PR](https://github.com/clientIO/joint/pull/2625/files).
It will be fixed by https://github.com/clientIO/joint/pull/2720.



Fix (patch):
diff --git a/packages/joint-core/src/linkTools/Arrowhead.mjs b/packages/joint-core/src/linkTools/Arrowhead.mjs
index afcc1be39..e2d426137 100644
--- a/packages/joint-core/src/linkTools/Arrowhead.mjs
+++ b/packages/joint-core/src/linkTools/Arrowhead.mjs
@@ -51,7 +51,8 @@ const Arrowhead = ToolView.extend({
         var paper = relatedView.paper;
         relatedView.model.startBatch('arrowhead-move', { ui: true, tool: this.cid });
         relatedView.startArrowheadMove(this.arrowheadType);
-        this.delegateDocumentEvents();
+        const data = evt.data || (evt.data = {});
+        this.delegateDocumentEvents(null, data);
         paper.undelegateEvents();
         this.focus();
         this.el.style.pointerEvents = 'none';
Repository: zotero/zotero (JavaScript)

Issue:
Local search fails when an attachment has an erroneous path
The local search API returns 500 Internal Server Error if an attachment has an erroneous path. Tested on `7.1-beta.6+9f83790ed` and `7.1-beta.7+296edc3fd`

I found out that an `NS_ERROR_FILE_UNRECOGNIZED_PATH` for one attachment causes an `OperationError` in the server file, and thus the query fails. Removing this file resolves the issue.

```
(3)(+0000026): DOMException: Could not stat `C:\Users\Leon Staufer\OneDrive - redacted e.V\assets\fishmap.JPG': could not parse path (NS_ERROR_FILE_UNRECOGNIZED_PATH) OperationError: Could not stat `C:\Users\Leon Staufer\OneDrive - redacted e.V\assets\fishmap.JPG': could not parse path (NS_ERROR_FILE_UNRECOGNIZED_PATH) getFileSize@chrome://zotero/content/xpcom/data/item.js:5644:31 Zotero.Item.prototype.toResponseJSONAsync@chrome://zotero/content/xpcom/data/item.js:5664:52 From previous event: Zotero.Server.DataListener.prototype._headerFinished@chrome://zotero/content/xpcom/server.js:329:10 Zotero.Server.DataListener.prototype.onDataAvailable@chrome://zotero/content/xpcom/server.js:217:12
```

Ideally, a single document with an erroneous path should not break the local search API, and instead just remove this result.

Discovered through https://github.com/vanakat/zotero-link/issues/16#issuecomment-2614184748


Discussion: @dstillman: While we're at it, should we change [this](https://github.com/zotero/zotero/blob/7a467b8bfa24ebd78bedbce389aa9678a8150914/chrome/content/zotero/xpcom/data/item.js#L5663-L5677) to behave consistently? Right now, if the request was for an attachment item, it only adds the file size if it's an imported attachment, but if the request was for a parent item, it adds the file sizes of all attachments, imported or not. I don't really see a reason not to add file sizes for all attachments in every case. (Obviously that isn't consistent with the dataserver because it doesn't have access to linked attachments.)
Ah, I guess linked files have no `links.enclosure`. We could change that, but seems out of scope of this issue.



Fix (patch):
diff --git a/chrome/content/zotero/xpcom/data/item.js b/chrome/content/zotero/xpcom/data/item.js
index 1aab0ff396d..0cbb4c27971 100644
--- a/chrome/content/zotero/xpcom/data/item.js
+++ b/chrome/content/zotero/xpcom/data/item.js
@@ -5652,12 +5652,13 @@ Zotero.Item.prototype.toResponseJSONAsync = async function (options = {}) {
 				return (await IOUtils.stat(path)).size;
 			}
 			catch (e) {
-				if (e.name != 'NotFoundError') {
+				if (e.name != 'NotFoundError'
+						&& !(e.name == 'OperationError' && e.message.includes('NS_ERROR_FILE_UNRECOGNIZED_PATH'))) {
 					throw e;
 				}
 			}
 		}
-		return undefined
+		return undefined;
 	}
 	
 	let json = this.toResponseJSON(options);
Repository: zotero/zotero (JavaScript)

Issue:
Items in trash shouldn't show up in Related tab for items not in trash
But items not in the trash should appear for items in the trash. If both items are in the trash, the items should appear.

https://forums.zotero.org/discussion/81033/items-in-trash-appear-in-the-list-of-related-items



Fix (patch):
diff --git a/chrome/content/zotero/elements/relatedBox.js b/chrome/content/zotero/elements/relatedBox.js
index 4ef7a4ff5dd..a7d54ff94a0 100644
--- a/chrome/content/zotero/elements/relatedBox.js
+++ b/chrome/content/zotero/elements/relatedBox.js
@@ -85,17 +85,7 @@ import { getCSSItemTypeIcon } from 'components/icons';
 			body.replaceChildren();
 
 			if (this._item) {
-				let relatedKeys = this._item.relatedItems;
-				
-				let relatedItems = relatedKeys.map((key) => {
-					let item = Zotero.Items.getByLibraryAndKey(this._item.libraryID, key);
-					if (!item) {
-						Zotero.debug(`Related item ${this._item.libraryID}/${key} not found `
-							+ `for item ${this._item.libraryKey}`, 2);
-					}
-					return item;
-				}).filter(Boolean);
-				
+				let relatedItems = this._getRelatedItems();
 				// Sort by display title
 				var collation = Zotero.getLocaleCollation();
 				var titles = new Map();
@@ -225,7 +215,7 @@ import { getCSSItemTypeIcon } from 'components/icons';
 		}
 
 		_updateCount() {
-			let count = this._item.relatedItems.length;
+			let count = this._getRelatedItems().length;
 			this._section.setCount(count);
 		}
 
@@ -233,6 +223,25 @@ import { getCSSItemTypeIcon } from 'components/icons';
 			return this.querySelector(`[id=${id}]`);
 		}
 
+		_getRelatedItems() {
+			let relatedKeys = this._item.relatedItems;
+			
+			let relatedItems = relatedKeys.map((key) => {
+				let item = Zotero.Items.getByLibraryAndKey(this._item.libraryID, key);
+				if (!item) {
+					Zotero.debug(`Related item ${this._item.libraryID}/${key} not found `
+						+ `for item ${this._item.libraryKey}`, 2);
+				}
+				return item;
+			}).filter(Boolean);
+
+			// Unless the item itself is trashed, filter out trashed related items
+			if (!this._item.deleted) {
+				relatedItems = relatedItems.filter(item => !item.deleted);
+			}
+			return relatedItems;
+		}
+
 		receiveKeyboardFocus(_direction) {
 			this._id("addButton").focus();
 			// TODO: the relatedbox is not currently keyboard accessible
Repository: facebook/stylex (JavaScript)

Issue:
CamelCased variable names are unexpected turned into kebab-case when setting them
Previously, all variable names are always hashes that only included small-case letters.

Now, with the `debug` option set to true, variables are prefixed with their in-source key name.

This behavior has exposed a bug in how StyleX set the values of CSS variables. We always convert camelCase to kebab-case for CSS properties. We need to exclude CSS variables.



Fix (patch):
diff --git a/apps/nextjs-example/app/CardTokens.stylex.ts b/apps/nextjs-example/app/CardTokens.stylex.ts
index ef9609290..70ca9268f 100644
--- a/apps/nextjs-example/app/CardTokens.stylex.ts
+++ b/apps/nextjs-example/app/CardTokens.stylex.ts
@@ -10,5 +10,5 @@
 import * as stylex from '@stylexjs/stylex';
 
 export const tokens = stylex.defineVars({
-  arrow_transform: 'translateX(0)',
+  arrowTransform: 'translateX(0)',
 });
diff --git a/apps/nextjs-example/components/Card.tsx b/apps/nextjs-example/components/Card.tsx
index 9382dc9cc..3f2de3e6d 100644
--- a/apps/nextjs-example/components/Card.tsx
+++ b/apps/nextjs-example/components/Card.tsx
@@ -68,7 +68,7 @@ const styles = stylex.create({
     transitionDuration: '400ms',
     textAlign: 'center',
     textDecoration: 'none',
-    [tokens.arrow_transform]: {
+    [tokens.arrowTransform]: {
       default: 'translateX(0)',
       ':hover': 'translateX(4px)',
     },
@@ -85,7 +85,7 @@ const styles = stylex.create({
   span: {
     display: 'inline-block',
     transitionProperty: 'transform',
-    transform: tokens.arrow_transform,
+    transform: tokens.arrowTransform,
     transitionDuration: {
       default: '200ms',
       [REDUCE_MOTION]: '0s',
diff --git a/packages/shared/src/convert-to-className.js b/packages/shared/src/convert-to-className.js
index e45c461a2..7b6179c5c 100644
--- a/packages/shared/src/convert-to-className.js
+++ b/packages/shared/src/convert-to-className.js
@@ -31,7 +31,7 @@ export function convertStyleToClassName(
 ): StyleRule {
   const { classNamePrefix = 'x', debug = false } = options;
   const [key, rawValue] = objEntry;
-  const dashedKey = dashify(key);
+  const dashedKey = key.startsWith('--') ? key : dashify(key);
 
   let value: string | $ReadOnlyArray<string> = Array.isArray(rawValue)
     ? rawValue.map((eachValue) => transformValue(key, eachValue, options))
Repository: facebook/stylex (JavaScript)

Issue:
`sort-keys` comparing `default` with parent property
### Describe the issue

The new `sort-keys` eslint rule seems to give some unexpected errors, suggesting it's comparing the inner keys with parent keys.

![image](https://github.com/facebook/stylex/assets/6232457/71bc6a85-4c99-4dca-9bd2-feef7ac49871)

### Expected behavior

It's expected that the test case below is valid, however it errors with the message

> StyleX property key "default" should be above "maxWidth".

### Steps to reproduce

`@stylexjs/eslint-plugin@0.5.1`

- Add new test case in `packages/eslint-plugin/__tests__/stylex-sort-keys-test.js` with the below test case as a valid case
- Run `npm run test -w @stylexjs/eslint-plugin` and observe test failure with message `StyleX property key "default" should be above "maxWidth"`

### Test case

```js
      import stylex from 'stylex';
      const styles = stylex.create({
        nav: {
          maxWidth: {
            default: "1080px",
            ["@media (min-width: 2000px)"]: "calc((1080 / 24) * 1rem)"
          },
          paddingVertical: 0,
        },
      });
```

### Additional comments

_No response_



Fix (patch):
diff --git a/packages/eslint-plugin/src/stylex-sort-keys.js b/packages/eslint-plugin/src/stylex-sort-keys.js
index ff3da7f43..fe51dc5c6 100644
--- a/packages/eslint-plugin/src/stylex-sort-keys.js
+++ b/packages/eslint-plugin/src/stylex-sort-keys.js
@@ -169,7 +169,7 @@ const stylexSortKeys = {
           objectExpressionNestingLevel++;
         }
 
-        if (objectExpressionNestingLevel === 1) {
+        if (objectExpressionNestingLevel > 0) {
           stack = {
             upper: stack,
             prevNode: null,
Repository: wevm/viem (TypeScript)

Issue:
bug: `parseUnits` strips leading zero's of the factional causing wrong results
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Package Version

0.3.43

### Current Behavior

`parseUnits("630.0056882018259", 6)` results in `6305688n`



### Expected Behavior

`parseUnits("630.0056882018259", 6)` results in `630005688n`

### Steps To Reproduce

see above

### Link to Minimal Reproducible Example (StackBlitz, CodeSandbox, GitHub repo etc.)

_No response_

### Anything else?

_No response_



Fix (patch):
diff --git a/src/utils/unit/parseUnits.ts b/src/utils/unit/parseUnits.ts
index 5b07a386a2..2accc74dd2 100644
--- a/src/utils/unit/parseUnits.ts
+++ b/src/utils/unit/parseUnits.ts
@@ -17,7 +17,7 @@ export function parseUnits(value: `${number}`, decimals: number) {
       fraction.slice(decimals),
     ]
     fraction = `${
-      /^0+$/.test(before) ? before.slice(0, before.length - 1) : ''
+      /^0+/.test(before) ? before.slice(0, before.length - 1) : ''
     }${Math.round(Number(`${before}.${after}`))}`
   } else {
     fraction = fraction.padEnd(decimals, '0')