profile
viewpoint
Mateusz Burzyński Andarist @livechat Wrocław, Poland

Andarist/babel-plugin-annotate-pure-calls 62

This plugins helps with annotating top level functions calls with #__PURE__ comment.

aaronshaf/react-callbag-subject 8

Asynchronous pipelines in React using callbags

aaronshaf/callbag-gamepads 7

Callbag source for connected gamepad inputs

aaronshaf/callbag-animation-frames 5

Callbag listenable source sending DOMHighResTimeStamp at display refresh rate

aaronshaf/callbag-keyboard 3

Callbag source for the keyboard

Andarist/are-hook-inputs-equal 3

A comparator function for previous and current React hook inputs.

aaronshaf/callbag-flatten-iter 2

Callbag operator that flattens iterables

Andarist/babel-check-duplicated-nodes 1

🐠 Babel helper module for transforms authors to check the AST against duplicated nodes.

PullRequestReviewEvent

delete branch davidkpiano/xstate

delete branch : davidkpiano/remove-csb-ci

delete time in 16 minutes

push eventdavidkpiano/xstate

David Khourshid

commit sha d8f765586b82bf191727d463b6b05019716d0b55

Remove codesandbox CI config (#1489)

view details

push time in 16 minutes

PR merged davidkpiano/xstate

Remove codesandbox CI config

This PR removes CodeSandbox CI config.

We disabled it as it was seldom used and is now failing .

+0 -10

1 comment

1 changed file

davidkpiano

pr closed time in 16 minutes

issue commentemotion-js/emotion

Vendor prefix for animation property missing in production mode

I wonder then why does it work in when NODE_ENV !== 'production', insertRule is not used?

Yes, insertRule is not used but we rather set textContext on created script elements. It works like that to support source maps etc in dev mode.

F0LI4GE

comment created time in 17 minutes

Pull request review commentatlassian/changesets

feat(config): allow to provide glob expressions for linked and ignore packages

 function getNormalisedChangelogOption(   return thing; } +function normalizePackageNames(+  listOfPackageNamesOrGlob: readonly string[],+  pkgNames: readonly string[]+): string[] {+  // Resolve and expand possible glob esxpressions.+  return listOfPackageNamesOrGlob.reduce<string[]>(+    (allResolvedPackageNames, pkgNameOrGlob) => {+      const matchingPackages = pkgNames.filter(pkgName =>+        micromatch.isMatch(pkgName, pkgNameOrGlob)

In lerna for ignoring packages they have a specific option, for example: https://github.com/lerna/lerna/blob/c0a750e0f482c16dda2f922f235861283efbe94d/commands/list/tests/list-command.test.js#L353-L356

Right, this is somewhat similar - but is for CLI args. I was asking more about how workspaces config gets interpreted. It's acquired from the config here. This gets later resolved by fileFinder - it seems that the results of those globs are just concatenated. So I would assume that this just works like the implementation proposed by you - would be great to confirm this though.

It this is true - and you can't easily mix inclusive and exclusive patterns there then I think it's acceptable for us to do the same and, if needed, implement the proposed solution with { include, exclude } object.

emmenko

comment created time in 6 hours

PullRequestReviewEvent

PR opened devanshj/xstate

Tweak internal call sites affected by removal of the indexer type wit…

…h a value of type any from ActionObject

+44 -17

0 comment

7 changed files

pr created time in 16 hours

create barnchdevanshj/xstate

branch : tweak-internals-after-type-changes

created branch time in 16 hours

Pull request review commentatlassian/changesets

feat(config): allow to provide glob expressions for linked and ignore packages

 function getNormalisedChangelogOption(   return thing; } +function normalizePackageNames(+  listOfPackageNamesOrGlob: readonly string[],+  pkgNames: readonly string[]+): string[] {+  // Resolve and expand possible glob esxpressions.+  return listOfPackageNamesOrGlob.reduce<string[]>(+    (allResolvedPackageNames, pkgNameOrGlob) => {+      const matchingPackages = pkgNames.filter(pkgName =>+        micromatch.isMatch(pkgName, pkgNameOrGlob)

One place that comes to my mind that we could look into how they have solved are workspace settings in yarn/lerna. Those are glob-based as well

emmenko

comment created time in a day

PullRequestReviewEvent

issue commentdavidkpiano/xstate

assign failed silently during async transition

That has to be some CS quirk though, the error is logged correctly to the browser's console in both cases and if we'd add an additional console.error then you'd end up with duplicates.

connectdotz

comment created time in 2 days

issue commentdavidkpiano/xstate

assign failed silently during async transition

For V4 it might make sense a quick patch where error caught in actions is at least logged with console.error so we are not driving in blind in case a mistake happens. In DEV mode only should be good enough.

But arent those logged automatically? Those are just uncaught errors right now so should be logged by the browser. I've adjusted the @connectdotz codesandbox' to switch to the sync mode and that error is being logged: https://codesandbox.io/s/silent-failure-example2-forked-hcnlp?file=/src/index.ts:402-423

connectdotz

comment created time in 2 days

Pull request review commentatlassian/changesets

feat(config): allow to provide glob expressions for linked and ignore packages

 function getNormalisedChangelogOption(   return thing; } +function normalizePackageNames(+  listOfPackageNamesOrGlob: readonly string[],+  pkgNames: readonly string[]+): string[] {+  // Resolve and expand possible glob esxpressions.+  return listOfPackageNamesOrGlob.reduce<string[]>(+    (allResolvedPackageNames, pkgNameOrGlob) => {+      const matchingPackages = pkgNames.filter(pkgName =>+        micromatch.isMatch(pkgName, pkgNameOrGlob)

How such groups with multiple patterns are handled by other tools? Could we take a look at prior work done by others?

emmenko

comment created time in 2 days

PullRequestReviewEvent

issue commentemotion-js/emotion

Unterminated comment literal causes infinite loop

@emotion/core has been renamed to @emotion/react. People have found out the previous name to be really confusing and we've decided to rename it. When upgrading a simple find&replace all should do the trick for this change.

philip-peterson

comment created time in 2 days

issue commentdavidkpiano/xstate

assign failed silently during async transition

I see what might be the confusion... The try/catch will never catch the async errors, unless like you said if the send() method returns a promise, which I think makes sense too, or maybe a separate API like sendAsync().

This doesn't make a conceptual sense though. send can't return a promise because it doesn't await for anything - there is no moment in which we could consider it to be resolved. Basically think of send always as an async operation - it's only synchronous because we don't force it to be async, but conceptually it totally is. The mere meaning of it is "schedule an event on this target", but that target can be anywhere - it doesn't even have to live on your machine.

Maybe we can also consider adding a system-termination state or an onError on the StateNode for the uncaught error, much like the onDone to report reaching the final state... just some thoughts

Some sort of such behavior would be most desired I believe.


If you switch to the test tab in CS, the test fails, because it was unable to catch the error, synchronously.

So actually... no error should be even possible to be caught synchronously by a catch block wrapping the service.send. As mentioned here - send is always considered to be async. If we consider SCXML spec - all runtime errors should be converted to error.execution events and should be just raised on the machine. I don't quite believe that it's perfect though because it means that if you don't handle this special event then errors are effectively just swallowed. That's I believe that the error handling should be reconsidered by us and we should stop the machine and propagate error to the consumer through other channels (first try to propagate to a parent etc, so it could handle a failure in its onError handler). This is just tentative thought on my side though (the last part). The whole topic needs deep analysis.

connectdotz

comment created time in 2 days

issue commentdavidkpiano/xstate

assign failed silently during async transition

Could u prepare a repro case of what you are experiencing? I think I might still be missing something. Rejected promises should trigger onError handlers correctly so those wouldnt be lost.

connectdotz

comment created time in 2 days

issue commentdavidkpiano/xstate

assign failed silently during async transition

Hm, I'm not sure if I understand your concerns @FredyC , could you clarify them more? From what I understand @connectdotz issue is not really about being able to make test assertions on anything, the test is just written to showcase a particular behavior and the issue itself is about that behavior. Quoting the "expected outcome" by the OP:

either invoke onError() of the invoke or terminate the interpreter as the sync-operation does.

connectdotz

comment created time in 2 days

issue commentdavidkpiano/xstate

assign failed silently during async transition

onError is a synctatic sugar for a transition for receiving an error event from the invoked service - this error happens in the parent machine though and this it shouldnt be triggered in my opinion, even though this might sound counter intuitive at first.

As this error has not been handled properly in the machine that has causes it (the parent one here) it should probably fail that machine, stop it, etc. Its part of the bogger story for v5 - we need to design error handling properly, so the rules can be written down and known to people. Changing this right now - in v4 - would be a breaking change.

connectdotz

comment created time in 2 days

Pull request review commentdavidkpiano/xstate

[@xstate/react] Add lazy machine initialization, simplify useActor

 describe('useService hook', () => {     });   }); -  it('service actions should be configurable', () => {-    const counterService = interpret(counterMachine).start();--    const Counter = () => {-      const [state, send] = useService(counterService);-      const [otherState, setOtherState] = useState('');--      useEffect(() => {-        counterService.execute(state, {

This test was IMHO incorrect - using this pattern there is a reasonably high chance that this action would not be executed. The only way to truly be sure that an action is going to be executed is to put it inline or in an actions object.

davidkpiano

comment created time in 2 days

PullRequestReviewEvent

push eventdavidkpiano/xstate

Mateusz Burzyński

commit sha 8445cff8f10dc875b97945abb2b7a5e80d1259bc

Bring back throwing on events sent to uninitialized services without defered events

view details

push time in 2 days

push eventdavidkpiano/xstate

Mateusz Burzyński

commit sha 26877263c10680fccec07ccfe35a144b5b0303b5

Do not warn about events sent to uninitialized service with defered events

view details

Mateusz Burzyński

commit sha a194d7e1fe538a6ddf8235752ba445bb5217236d

Provide dummy action to suppress unimplemented action warning and remove test presenting a wrong pattern

view details

push time in 2 days

push eventdavidkpiano/xstate

Mateusz Burzyński

commit sha 9677605c0f1b3a50492f8d10541c710dc972b155

Fixed act-related warnings in test

view details

push time in 2 days

issue commentatlassian/changesets

Error: could not parse changeset - invalid frontmatter: ---

It might also be just not handling newlines on Windows correctly because this fails:

`---
"@mri/components": patch
---

Several small changes for tooling or CI, related to transition from rush.js back to PNPM and changesets.`
.split('\n')
.join('\r\n')
.match(/\s*---([^]*?)\n\s*---\n([^]*)/)
nategreen

comment created time in 2 days

issue commentatlassian/changesets

Error: could not parse changeset - invalid frontmatter: ---

Could you check if maybe you have some additional whitespace after the second --- but before the line break?

nategreen

comment created time in 2 days

Pull request review commentmui-org/material-ui

[docs] Add emotion dependencies in codesandbox examples

 function includePeerDependencies(deps, versions) {   Object.assign(deps, {     'react-dom': versions['react-dom'],     react: versions.react,+    '@emotion/core': versions['@emotion/core'],+    '@emotion/styled': versions['@emotion/styled'],

Styled pkg doesnt create any singletones - it only consumes them.

mnajdova

comment created time in 2 days

PullRequestReviewEvent

Pull request review commentemotion-js/emotion

Proof of concept support for automatic jsx runtime

+/* eslint-disable no-unused-vars */+import * as React from 'react'+import { withEmotionCache, ThemeContext } from './context'+import { getRegisteredStyles, insertStyles } from '@emotion/utils'+import { isBrowser } from './utils'+import { serializeStyles } from '@emotion/serialize'++import { jsx as reactJsx, Fragment, createElement } from 'react/jsx-runtime'++const sanitizeIdentifier = identifier => identifier.replace(/\$/g, '-')++let typePropName = '__EMOTION_TYPE_PLEASE_DO_NOT_USE__'++let labelPropName = '__EMOTION_LABEL_PLEASE_DO_NOT_USE__'++let hasOwnProperty = Object.prototype.hasOwnProperty++let render = (cache, props, theme, ref) => {+  let cssProp = theme === null ? props.css : props.css(theme)++  // so that using `css` from `emotion` and passing the result to the css prop works+  // not passing the registered cache to serializeStyles because it would+  // make certain babel optimisations not possible+  if (typeof cssProp === 'string' && cache.registered[cssProp] !== undefined) {+    cssProp = cache.registered[cssProp]+  }++  let type = props[typePropName]+  let registeredStyles = [cssProp]+  let className = ''++  if (typeof props.className === 'string') {+    className = getRegisteredStyles(+      cache.registered,+      registeredStyles,+      props.className+    )+  } else if (props.className != null) {+    className = `${props.className} `+  }++  let serialized = serializeStyles(registeredStyles)++  if (+    process.env.NODE_ENV !== 'production' &&+    serialized.name.indexOf('-') === -1+  ) {+    let labelFromStack = props[labelPropName]+    if (labelFromStack) {+      serialized = serializeStyles([+        serialized,+        'label:' + labelFromStack + ';'+      ])+    }+  }+  const rules = insertStyles(cache, serialized, typeof type === 'string')+  className += `${cache.key}-${serialized.name}`++  const newProps = {}+  for (let key in props) {+    if (+      hasOwnProperty.call(props, key) &&+      key !== 'css' &&+      key !== typePropName &&+      (process.env.NODE_ENV === 'production' || key !== labelPropName)+    ) {+      newProps[key] = props[key]+    }+  }+  newProps.ref = ref+  newProps.className = className++  const ele = jsx(type, newProps)+  if (!isBrowser && rules !== undefined) {+    let serializedNames = serialized.name+    let next = serialized.next+    while (next !== undefined) {+      serializedNames += ' ' + next.name+      next = next.next+    }+    return (+      <React.Fragment>+        <style+          {...{+            [`data-emotion-${cache.key}`]: serializedNames,+            dangerouslySetInnerHTML: { __html: rules },+            nonce: cache.sheet.nonce+          }}+        />+        {ele}+      </React.Fragment>+    )+  }+  return ele+}++let Emotion = /* #__PURE__ */ withEmotionCache((props, cache, ref) => {+  // use Context.read for the theme when it's stable+  if (typeof props.css === 'function') {+    return (+      <ThemeContext.Consumer>+        {theme => render(cache, props, theme, ref)}+      </ThemeContext.Consumer>+    )+  }+  return render(cache, props, null, ref)+})++if (process.env.NODE_ENV !== 'production') {+  Emotion.displayName = 'EmotionCssPropInternal'+}++const jsx = (type, props, maybeKey) => {+  let args = arguments++  if (props == null || !hasOwnProperty.call(props, 'css')) {+    return reactJsx(type, props, maybeKey)+  }++  if (+    process.env.NODE_ENV !== 'production' &&+    typeof props.css === 'string' &&+    // check if there is a css declaration+    props.css.indexOf(':') !== -1+  ) {+    throw new Error(+      `Strings are not allowed as css prop values, please wrap it in a css template literal from '@emotion/css' like this: css\`${+        props.css+      }\``+    )+  }++  let argsLength = args.length++  let createElementArgArray = new Array(argsLength)++  createElementArgArray[0] = Emotion+  let newProps = {}++  for (let key in props) {+    if (hasOwnProperty.call(props, key)) {+      newProps[key] = props[key]+    }+  }+  newProps[typePropName] = type+  if (process.env.NODE_ENV !== 'production') {+    let error = new Error()+    if (error.stack) {+      // chrome+      let match = error.stack.match(+        /at (?:Object\.|Module\.|)jsx.*\n\s+at ([A-Z][A-Za-z$]+) /+      )+      if (!match) {+        // safari and firefox+        match = error.stack.match(/.*\n([A-Z][A-Za-z$]+)@/)+      }+      if (match) {+        newProps[labelPropName] = sanitizeIdentifier(match[1])+      }+    }+  }++  createElementArgArray[1] = newProps++  for (let i = 2; i < argsLength; i++) {+    createElementArgArray[i] = args[i]+  }+  // $FlowFixMe+  return reactJsx.apply(null, createElementArgArray)+}++const jsxs = jsx

This would be preferable. I was under impression that React 17 still supports React.createElement, and the only addition is react/jsx-runtime entrypoint.

Yes, that's correct.

Emotion would have to export three things to match React's exports.

That's correct as well - the only problematic part is that TypeScript doesn't import fully automatic runtime with custom modules 😞 but that's kinda their limitation and not ours, even though it affects us greatly.

(*) There's a warning about explicitly using new jsx functions in React docs. It's probably meant for projects that don't implement their own jsx function, though.

Yes, I believe we don't have to care about this warning - API of those functions have to be stable after all, otherwise, compilers would break, so we should be free to use them directly.

I'm not sure yet how react/jsx-dev-runtime fits the puzzle.

I think it's the same - we should just forward stuff to the appropriate function and that's all.

FLGMwt

comment created time in 2 days

PullRequestReviewEvent

issue commentemotion-js/emotion

Unterminated comment literal causes infinite loop

Just check npm versions - we have released some this month. I think .17 or .18 might be latest, but please recheck that.

philip-peterson

comment created time in 2 days

issue commentemotion-js/emotion

Unterminated comment literal causes infinite loop

The input code looked like below. I'm guessing that perhaps nesting a single line comment inside of a multi-line comment caused it?

Hard to tell. You would have to prepare a runnable repro case so I could take a look at this.

@Andarist I just hit this, or something closely related. The issue only occurs after bundling our project. I'd guess I've hit this sort of bug 5 or 6 times over the past year; always only triggered in our bundled production build. Again it does appear to be a Stylis bug though.

I strongly recommend checking out v11 - it's almost ready and includes Stylis v4 that has resolved all known issues that Stylis v3 had.

philip-peterson

comment created time in 3 days

Pull request review commentdavidkpiano/xstate

Add utility types for typestates

 The typestates of a machine are specified as the 3rd generic type in `createMach **Example:**  ```ts-import { createMachine, interpret } from 'xstate';+import {+  CombineTypestates,+  TypestateContext,+  createMachine,+  interpret+} from 'xstate';  interface User {   name: string; } -interface UserContext {-  user?: User;-  error?: string;-}- type UserEvent =   | { type: 'FETCH'; id: string }   | { type: 'RESOLVE'; user: User }   | { type: 'REJECT'; error: string }; -type UserState =-  | {-      value: 'idle';-      context: UserContext & {-        user: undefined;-        error: undefined;-      };-    }-  | {-      value: 'loading';-      context: UserContext;-    }-  | {-      value: 'success';-      context: UserContext & { user: User; error: undefined };-    }-  | {-      value: 'failure';-      context: UserContext & { user: undefined; error: string };-    };+type UserState = CombineTypestates<+  | { value: 'idle'; context: {} }+  | { value: 'loading'; context: { user?: User; error?: string } }+  | { value: 'success'; context: { user: User } }+  | { value: 'failure'; context: { error: string } }+>;++type UserContext = TypestateContext<UserState>;

TypestateContext requires a union where each context type has every key present, including the ones that are always undefined for the state value. So it's is actually identical to:

How useful CombineTypestates is then? The main benefit I'm seeing (but I, of course, might be missing something) is the ability to merge/combine typestates to create a "typestate context". If that's the main appeal - why TypestateContext doesn't just "call" CombineTypestates internally (so it could be used like on the example I've given)?

The ideal API in my mind (maybe for v5?) would require only two generic params, and could use TypeScript 4.1 string template types

The idea of having this as an object with paths as the keys is appealing. Not sure if you have meant that - but I don't think TContext should be completely gone. It's by far easier to use than typestates and actually provides type safety, whereas using typestates can lead to runtime bugs because we can't guarantee that the declared types match the reality.

sbking

comment created time in 3 days

PullRequestReviewEvent

Pull request review commentdavidkpiano/xstate

Add utility types for typestates

 The typestates of a machine are specified as the 3rd generic type in `createMach **Example:**  ```ts-import { createMachine, interpret } from 'xstate';+import {+  CombineTypestates,+  TypestateContext,+  createMachine,+  interpret+} from 'xstate';  interface User {   name: string; } -interface UserContext {-  user?: User;-  error?: string;-}- type UserEvent =   | { type: 'FETCH'; id: string }   | { type: 'RESOLVE'; user: User }   | { type: 'REJECT'; error: string }; -type UserState =-  | {-      value: 'idle';-      context: UserContext & {-        user: undefined;-        error: undefined;-      };-    }-  | {-      value: 'loading';-      context: UserContext;-    }-  | {-      value: 'success';-      context: UserContext & { user: User; error: undefined };-    }-  | {-      value: 'failure';-      context: UserContext & { user: undefined; error: string };-    };+type UserState = CombineTypestates<+  | { value: 'idle'; context: {} }+  | { value: 'loading'; context: { user?: User; error?: string } }+  | { value: 'success'; context: { user: User } }+  | { value: 'failure'; context: { error: string } }+>;++type UserContext = TypestateContext<UserState>;

how is this different from:

type UserContext = TypestateContext<
  | { value: 'idle'; context: {} }
  | { value: 'loading'; context: { user?: User; error?: string } }
  | { value: 'success'; context: { user: User } }
  | { value: 'failure'; context: { error: string } }
>;
sbking

comment created time in 3 days

PullRequestReviewEvent

Pull request review commentdavidkpiano/xstate

Add utility types for typestates

 export interface Typestate<TContext> {   context: TContext; } +type KeyOfUnion<T> = T extends unknown ? keyof T : never;++type MergeUnion<T> = {+  [K in keyof T]: T[K];+} &+  {+    [K in Exclude<KeyOfUnion<T>, keyof T>]?: T extends Record<K, any>+      ? T[K] | undefined+      : never;+  };++export type CombineTypestates<+  TStates extends Typestate<any>+> = TStates['context'] extends infer C+  ? TStates extends Typestate<any>+    ? {+        value: TStates['value'];+        context: {+          [K in keyof (MergeUnion<C> &+            TStates['context'])]: K extends keyof TStates['context']+            ? TStates['context'][K]+            : undefined;+        };+      }+    : never+  : never;++export type CombineTypestateTuples<

when one would like to use this in the real app? CombineTypestates seems to be sufficient, especially given that it works on data shape that we document

sbking

comment created time in 3 days

PullRequestReviewEvent

issue commentatlassian/changesets

Error: could not parse changeset - invalid frontmatter: ---

Looking at the regex parsing the front matter, it looks like it is matching only when there is whitespace before the first ---:

Not quite, it allows any whitespace before --- but it doesn't require it. * is a quantifier that matches between 0 and unlimited times.

It's hard for me to tell why this would fail for you. Could you share a runnable repro case or try to debug this? If you could dump the exact char codes passed to parseChangeset (or whatever the final function is called) that could be very helpful.

nategreen

comment created time in 3 days

issue commentemotion-js/emotion

Vendor prefix for animation property missing in production mode

I haven't noticed this effect before but it seems that -webkit-animation is somehow handled in a special way by browsers when using insertRule API. I've debugged your repro and I can confirm that this property is being inserted - it just gets converted by a browser to a regular animation property. I've checked this in Chrome, Safari and Firefox and it behaves the same in all of them.

You can kinda confirm this by executing such script in a console:

var styleElement = document.createElement('style')
styleElement.dataset.test = 'foo'
document.head.appendChild(styleElement)
styleElement.sheet.insertRule('div { -webkit-animation: customname }', 0)

and inspecting any div on your page. Notice how it will have animation property, rather than -webkit-animation.

F0LI4GE

comment created time in 3 days

Pull request review commentemotion-js/emotion

Proof of concept support for automatic jsx runtime

+/* eslint-disable no-unused-vars */+import * as React from 'react'+import { withEmotionCache, ThemeContext } from './context'+import { getRegisteredStyles, insertStyles } from '@emotion/utils'+import { isBrowser } from './utils'+import { serializeStyles } from '@emotion/serialize'++import { jsx as reactJsx, Fragment, createElement } from 'react/jsx-runtime'++const sanitizeIdentifier = identifier => identifier.replace(/\$/g, '-')++let typePropName = '__EMOTION_TYPE_PLEASE_DO_NOT_USE__'++let labelPropName = '__EMOTION_LABEL_PLEASE_DO_NOT_USE__'++let hasOwnProperty = Object.prototype.hasOwnProperty++let render = (cache, props, theme, ref) => {+  let cssProp = theme === null ? props.css : props.css(theme)++  // so that using `css` from `emotion` and passing the result to the css prop works+  // not passing the registered cache to serializeStyles because it would+  // make certain babel optimisations not possible+  if (typeof cssProp === 'string' && cache.registered[cssProp] !== undefined) {+    cssProp = cache.registered[cssProp]+  }++  let type = props[typePropName]+  let registeredStyles = [cssProp]+  let className = ''++  if (typeof props.className === 'string') {+    className = getRegisteredStyles(+      cache.registered,+      registeredStyles,+      props.className+    )+  } else if (props.className != null) {+    className = `${props.className} `+  }++  let serialized = serializeStyles(registeredStyles)++  if (+    process.env.NODE_ENV !== 'production' &&+    serialized.name.indexOf('-') === -1+  ) {+    let labelFromStack = props[labelPropName]+    if (labelFromStack) {+      serialized = serializeStyles([+        serialized,+        'label:' + labelFromStack + ';'+      ])+    }+  }+  const rules = insertStyles(cache, serialized, typeof type === 'string')+  className += `${cache.key}-${serialized.name}`++  const newProps = {}+  for (let key in props) {+    if (+      hasOwnProperty.call(props, key) &&+      key !== 'css' &&+      key !== typePropName &&+      (process.env.NODE_ENV === 'production' || key !== labelPropName)+    ) {+      newProps[key] = props[key]+    }+  }+  newProps.ref = ref+  newProps.className = className++  const ele = jsx(type, newProps)+  if (!isBrowser && rules !== undefined) {+    let serializedNames = serialized.name+    let next = serialized.next+    while (next !== undefined) {+      serializedNames += ' ' + next.name+      next = next.next+    }+    return (+      <React.Fragment>+        <style+          {...{+            [`data-emotion-${cache.key}`]: serializedNames,+            dangerouslySetInnerHTML: { __html: rules },+            nonce: cache.sheet.nonce+          }}+        />+        {ele}+      </React.Fragment>+    )+  }+  return ele+}++let Emotion = /* #__PURE__ */ withEmotionCache((props, cache, ref) => {+  // use Context.read for the theme when it's stable+  if (typeof props.css === 'function') {+    return (+      <ThemeContext.Consumer>+        {theme => render(cache, props, theme, ref)}+      </ThemeContext.Consumer>+    )+  }+  return render(cache, props, null, ref)+})++if (process.env.NODE_ENV !== 'production') {+  Emotion.displayName = 'EmotionCssPropInternal'+}++const jsx = (type, props, maybeKey) => {+  let args = arguments++  if (props == null || !hasOwnProperty.call(props, 'css')) {+    return reactJsx(type, props, maybeKey)+  }++  if (+    process.env.NODE_ENV !== 'production' &&+    typeof props.css === 'string' &&+    // check if there is a css declaration+    props.css.indexOf(':') !== -1+  ) {+    throw new Error(+      `Strings are not allowed as css prop values, please wrap it in a css template literal from '@emotion/css' like this: css\`${+        props.css+      }\``+    )+  }++  let argsLength = args.length++  let createElementArgArray = new Array(argsLength)++  createElementArgArray[0] = Emotion+  let newProps = {}++  for (let key in props) {+    if (hasOwnProperty.call(props, key)) {+      newProps[key] = props[key]+    }+  }+  newProps[typePropName] = type+  if (process.env.NODE_ENV !== 'production') {+    let error = new Error()+    if (error.stack) {+      // chrome+      let match = error.stack.match(+        /at (?:Object\.|Module\.|)jsx.*\n\s+at ([A-Z][A-Za-z$]+) /+      )+      if (!match) {+        // safari and firefox+        match = error.stack.match(/.*\n([A-Z][A-Za-z$]+)@/)+      }+      if (match) {+        newProps[labelPropName] = sanitizeIdentifier(match[1])+      }+    }+  }++  createElementArgArray[1] = newProps++  for (let i = 2; i < argsLength; i++) {+    createElementArgArray[i] = args[i]+  }+  // $FlowFixMe+  return reactJsx.apply(null, createElementArgArray)+}++const jsxs = jsx

If anything we should just forward to whatever React exports - but I'm quite hesitant about moving forward with this PR at this point in time as React 17 is not released yet. We'll have to wait for it and then think how to support both React 16 and React 17 at the same time or if we should cut a new major for React 17.

FLGMwt

comment created time in 3 days

PullRequestReviewEvent

pull request commentemotion-js/emotion

RFC: Expose interface for custom CSSObject declaration

Please describe what issue this tries to solve.

tpict

comment created time in 4 days

PullRequestReviewEvent

issue commentredux-saga/redux-saga

uncaught at _callee3 at _callee3 at _callee6

Please always try to share a repro case in a runnable form - either by providing a git repository to clone or a codesandbox. OSS maintainers usually can't afford the time to set up the repro, even if exact steps are given.

jiangqinggouwa

comment created time in 4 days

pull request commentdavidkpiano/xstate

[@xstate/react] Add lazy machine initialization, simplify useActor

I've started looking into it but haven't found a quick win just yet - gonna get back to it tomorrow.

davidkpiano

comment created time in 5 days

pull request commentemotion-js/emotion

v11

As you can see here - there is only a single issue blocking us. I will be looking into it soon-ish. Other than that we'd like to support ESM in new node versions so we need to provide pkg.json#exports for all packages - that will be implemented in preconstruct which we are using to build our packages and from what I understand Mitchell has started working on that one a few days ago.

mitchellhamilton

comment created time in 5 days

pull request commentatlassian/changesets

Add `doNotThank` option to `@changeset/changelog-github`

You probably could reuse our implementation and just strip away what u want with by manipulating the returned string.

We have to balance lean API and community demands, lean API doesnt only mean fewer options but also, more importantly, it means a reduced complexity of our implementation. If we add everything that is being asked for we’d end up with unmanageable code. If this issue arise again in the future we might reconsider stance on this particular option but for now i think it’s not needed as it has only been requested by you, so we cant really classify it as a popular demand.

BeeeQueue

comment created time in 5 days

issue commentdavidkpiano/xstate

ESM loading fails for native Node.js@13.x.x loader

Just an update - we'll be providing "exports" field in the future in the XState 5. It's not yet implemented and nor v5 is ready to be shipped even as a prerelease but at least I have a plan now to make this happen. At this point in time, pkg.json#exports semantics seem to be pretty stable as webpack is going to ship support for it soon-ish, so it should be safe for us to start using that in the future.

hbarcelos

comment created time in 5 days

issue commentdavidkpiano/xstate

@xstate/fsm is generating es5 for the es/ build

It's not a common choice in the community because unflagging esm support in node and removing the scary warning has only happened quite recently, in the last few months: https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V12.md#2020-05-26-version-12170-erbium-lts-targos

I don't feel that those are at all related - syntax itself is not tied to the module format and there are some packages (node-only mostly) that have decided to use es6+ syntax in the shipped code, not looking at all at the CJS/ESM drama because those are 2 different things. You can totally use newer syntax while still be using CJS format.

There are no javascript runtimes that support es modules, but lack es6. There is no point in generating es modules that use that older syntax.

But there absolutely is a point in that - there are multiple targets one can think of and even if the final target environment doesn't support ESM there is still a middleman processor (like a bundler) between the package itself and the final app~. If a module syntax is important for such a middleman processor (and it is) then it's a totally valid choice to provide ESM files using only ES5 syntax besides the export/import statements.

At work our frontend code is able to feature detect when a browser supports es modules, and we load the newer code path written in es6. On average it's about 30% less lines of code. We don't want to ship modules written in es5 to newer browsers. That is a common community choice, and it's not ideal.

With this I can agree - it's not ideal at all. I'm just saying that shipping newer code by default is a different decision, not related to the module format and that it can be done, but should be evaluated carefully, because as package maintainers we have responsibilities for a lot of users with different use cases, different capabilities of customizing their build processes, etc. It's important for us to think about those. Changing the syntax level is also a breaking change so we only should be thinking about this when releasing a new major versions.

The code that xstate/fsm provides for ie11 already requires a bundler (both umd and es builds.) I don't think this changes that. Code intended for bundling still needs to be run through a bundler.

Yes, it's different matter though if something is meant to be processed by a bundler to load files/concatenate them etc than if it meant to be processed by a transpiler plugged into that bundler. Problem is that ignoring /node_modules/ from transpilation has been a recommendation for a very long time and there are many people doing just that. Even if this can be changed on their side it's still something that they will have to do and many might not know how or might break things in the process of changing this.

I would also like to see advancements in this field, but I don't see any in the community as a whole and I don't particularly feel like being a precursor here.

mreinstein

comment created time in 5 days

Pull request review commentnodejs/node

Refine "require" / "import" conditions constraints

 For example, a package that wants to provide different ES module exports for Node.js supports the following conditions out of the box:  * `"import"` - matched when the package is loaded via `import` or-   `import()`. Can reference either an ES module or CommonJS file, as both-   `import` and `import()` can load either ES module or CommonJS sources.-   _Always matched when the `"require"` condition is not matched._+   `import()`, or via any top-level load or resolve operation by the

or via any top-level load or resolve operation by the ECMAScript module loader.

are there any other such operations?

guybedford

comment created time in 5 days

PullRequestReviewEvent

delete branch changesets/bot

delete branch : update-deps

delete time in 5 days

push eventchangesets/bot

Mateusz Burzyński

commit sha c1d585ffc4137df4f0e471ed4ca80e2345b9b326

Update changesets-related deps (#15)

view details

push time in 5 days

PR merged changesets/bot

Reviewers
Update changesets-related deps

I believe this should bring better support for ignored packages and onlyUpdatePeerDependentsWhenOutOfRange option. If not - I will look into what should be done to support them.

+68 -65

1 comment

3 changed files

Andarist

pr closed time in 5 days

PR opened rollup/plugins

fix(babel): clone cached helper identifier before returning it

Rollup Plugin Name: babel

This PR contains:

  • [x] bugfix
  • [ ] feature
  • [ ] refactor
  • [ ] documentation
  • [ ] other

Are tests included?

  • [ ] yes (bugfixes and features will not be merged without tests)
  • [x] no

Breaking Changes?

  • [ ] yes (breaking changes will not be merged unless absolutely necessary)
  • [x] no

Description

I don't really have a failing test for this and I don't think it's worth testing any implementation details to just have this verified. Usually one doesn't have to worry about inserting duplicated nodes but it's a good practice to never do this and always insert fresh nodes.

+2 -2

0 comment

1 changed file

pr created time in 5 days

create barnchrollup/plugins

branch : fix/babel-bundled-helpers-plugin

created branch time in 5 days

Pull request review commentpreconstruct/preconstruct

Deduplicate babel helpers

-import * as babel from "@babel/core";-import { minify } from "terser";--export function transformBabel(code: string, options: any) {-  options = JSON.parse(options);-  return babel.transformAsync(code, options).then((res) => {-    let { code, map } = res!;-    return { code, map };+import { HELPERS } from "./constants";+import { lazyRequire } from "lazy-require.macro";+type LoadPartialConfigAsync = (+  options: babel.TransformOptions+) => Promise<Readonly<babel.PartialConfig> | null>;++function importHelperPlugin() {+  const { addNamed } = lazyRequire<+    // @ts-ignore+    typeof import("@babel/helper-module-imports")+  >();+  return {+    pre(file: any) {+      const cachedHelpers: Record<string, babel.types.Identifier> = {};+      file.set("helperGenerator", (name: string) => {+        if (!file.availableHelper(name)) {+          return null;+        }++        if (cachedHelpers[name]) {+          return cachedHelpers[name];+        }++        return (cachedHelpers[name] = addNamed(file.path, name, HELPERS));+      });+    },+  };+}+export async function transformBabel(+  code: string,+  cwd: string,+  filename: string+) {+  const babel = lazyRequire<typeof import("@babel/core")>();+  const config = await (+    ((babel as any).loadPartialConfigAsync as LoadPartialConfigAsync) ||+    babel.loadPartialConfig+  )({+    caller: {+      name: "rollup-plugin-babel",+      supportsStaticESM: true,+      supportsDynamicImport: true,+    },+    sourceMaps: true,+    cwd,+    filename,   });+  if (!config) {+    return null;+  }+  return babel+    .transformAsync(code, {+      ...config.options,+      // note that we're doing this whole thing because we want to add the plugin _before_ user's plugins+      // so that if they're using @babel/plugin-transform-runtime(which they should be), it'll work+      plugins: [importHelperPlugin, ...(config.options.plugins || [])],

Smart 👍

mitchellhamilton

comment created time in 5 days

PullRequestReviewEvent

issue commentdavidkpiano/xstate

[xstate-inspector] Waiting for connection

A requirement of calling inspect before anything else seems quite reasonable to me. OTOH baking things into XState itself (as in doing some registration within a constructor or anything else that belongs to us) would impose an additional cost (albeit not a very big one) for all consumers of XState - if we can avoid it I'm all in favour of avoiding things like this.

FredyC

comment created time in 6 days

Pull request review commentdavidkpiano/xstate

[v5] Higher-level guards

 export function stateIn<TContext, TEvent extends EventObject>(   }; } -export function stateNotIn<TContext, TEvent extends EventObject>(-  stateValue: StateValue-): GuardPredicate<TContext, TEvent> {+export function not<TContext, TEvent extends EventObject>(+  condition: Condition<TContext, TEvent>+): BooleanGuardObject<TContext, TEvent> {   return {-    type: 'xstate.guard',-    name: '!In',-    predicate: (_, __, { state }) => {-      if (isString(stateValue) && isStateId(stateValue)) {-        return state.configuration.every((sn) => sn.id !== stateValue.slice(1));-      }+    type: DEFAULT_GUARD_TYPE,+    op: 'not',+    children: [toGuard(condition)]+  };+} -      return !state.matches(stateValue);-    }+export function and<TContext, TEvent extends EventObject>(+  ...conditions: Array<Condition<TContext, TEvent>>

the best reference that i know is https://ramdajs.com/docs/#cond , other than that i don't have super strong preference for one over another

Some things that come to my mind:

  • variadic functions make .length unusable, this is a somewhat esoteric need so kinda whatever on that
  • the transpiled code is often worse as spread often creates a for loop over arguments
davidkpiano

comment created time in 6 days

PullRequestReviewEvent

issue commentmattpocock/xstate-codegen

Typestates?

I think that we shouldn't support custom typestates because it's an unsafe feature and the whole goal of this project is to provide type safety. Or rather - we should not allow them unless one makes a compelling case that they are way better over what we can provide out of the box.

That being said - computing typestates won't happen over night here so as a stopgap we can allow them for the time being but with a plan to remove the support for them when we reach the point of being able to compute them ourselves.

bard

comment created time in 6 days

pull request commentmui-org/material-ui

[Slider] Create unstyled version and migrate to emotion & styled-components

This PR has a lot of comments and I can't find the one that I would like to comment so... just going to do it here.

I've consulted Mitchell on why react-select specifies @emotion/core as a dep rather than a peerDep:

  1. it's mainly to create less friction - but if pkg managers start to auto-install peer deps then this might change in the future
  2. it's somewhat safe in their case because they don't expose theme anywhere, so at least mismatch on this singleton can't cause any issues
  3. caches can mismatch, but the worst case scenario some styles can get injected twice to the document - so they have decided that it's not a big deal
  4. this can be a problem if one uses a custom CacheProvider but they consider such people to be advanced users and that they should take care of ensuring that there is only a single @emotion/core in the dep tree, using yarn deduplicate, resolutions, or whatever
mnajdova

comment created time in 6 days

pull request commentatlassian/changesets

Add `doNotThank` option to `@changeset/changelog-github`

Isn't usually more information considered to be better than a lack of information? Those really seem quite harmless to me, even if a little bit excessive at times. You could rely on those to ask authors question regarding certain changes, rather than looking through git blame etc.

BeeeQueue

comment created time in 6 days

issue commentdavidkpiano/xstate

Issues completing nested Parallel states

This is an interesting problem and we are going to give this a thought but for now there no plans to deviate from the spec in such a way. We want XState to be interoperable with other implementations - so other tools can be used to model machines etc. I'm actively thinking about what could be done to revive the work on the spec itself though.

jpalof

comment created time in 6 days

issue commentdavidkpiano/xstate

machine ignores invocation when starting from arbitrary state

So is this the intended behaviour?

I can't be 100% sure - that's a question for @davidkpiano . I only have noticed what kind of problems changing the current behavior could cause.

I was trying to start the machine from a state to be able to test each transition separately, without having to 'play' through all the previous states and conditions, and introducing cross-dependencies.

I would say that you absolutely should not unit test machines like this - if you decide to drop XState as a dependency (which hopefully you won't 😉 ) then your tests will need to be refactored completely. Such tests are too tied to the underlying implementation and thus don't give you the desired confidence because you can't really change the code without changing the implementation.

kristofkalocsai

comment created time in 6 days

issue commentdavidkpiano/xstate

machine ignores invocation when starting from arbitrary state

This is a delicate matter - starting from a state is mainly supposed to be used when rehydrating machines. And in this context there are legitimate reasons why a service should not be started - it could, for example, reach its final state before and is not supposed to be activated again.

kristofkalocsai

comment created time in 6 days

Pull request review commentatlassian/changesets

Add `doNotThank` option to `@changeset/changelog-github`

 const changelogFunctions: ChangelogFunctions = {      return [changesetLink, ...updatedDepenenciesList].join("\n");   },-  getReleaseLine: async (changeset, type, options) => {-    if (!options || !options.repo) {+  getReleaseLine: async (changeset, type, options = {}) => {+    if (!options.repo) {       throw new Error(         'Please provide a repo to this changelog generator like this:\n"changelog": ["@changesets/changelog-github", { "repo": "org/repo" }]'       );     }++    const shouldThank = (user: string) => {+      // Handle an array of names to not thank

Let's first discuss the merit of this option - don't want you to put too much work into this one if we decide not to proceed with this one in the end (I'm not saying that we won't, yet).

BeeeQueue

comment created time in 6 days

PullRequestReviewEvent

Pull request review commentatlassian/changesets

Add `doNotThank` option to `@changeset/changelog-github`

 const changelogFunctions: ChangelogFunctions = {         commit: changeset.commit       });       return `\n\n- ${links.commit}${-        links.pull === null ? "" : ` ${links.pull}`+        links.pull == null ? "" : ` ${links.pull}`

I understand the difference - can undefined be even received here though?

BeeeQueue

comment created time in 6 days

PullRequestReviewEvent

Pull request review commentkriasoft/nodejs-api-starter

Add Emotion theme (example) to web

+/**+ * @copyright 2016-present Kriasoft (https://git.io/vMINh)+ */++import {} from "react";+import { Theme } from "@emotion/react";+import { Interpolation } from "@emotion/serialize";++declare module "@emotion/react" {+  interface Theme {+    mode: "light" | "dark";++    palette: {+      primary: string;+      secondary: string;+    };++    typography: {+      fontFamily: string;+    };+  }+}++declare module "react" {+  interface Attributes {+    css?: Interpolation<Theme>;

Have you encountered any problem with "@emotion/react/types/css-prop" approach?

koistya

comment created time in 6 days

PullRequestReviewEvent

Pull request review commentkriasoft/nodejs-api-starter

Add Emotion theme (example) to web

+/**+ * @copyright 2016-present Kriasoft (https://git.io/vMINh)+ */++import {} from "react";+import { Theme } from "@emotion/react";+import { Interpolation } from "@emotion/serialize";

isn't this type reexported from @emotion/react? I don't think you should depend on @emotion/serialize, it won't cause problems but it's really just an internal package for the most part, so people should not be expected to interact with it directly

koistya

comment created time in 6 days

PullRequestReviewEvent

Pull request review commentatlassian/changesets

Add `doNotThank` option to `@changeset/changelog-github`

 const changelogFunctions: ChangelogFunctions = {      return [changesetLink, ...updatedDepenenciesList].join("\n");   },-  getReleaseLine: async (changeset, type, options) => {-    if (!options || !options.repo) {+  getReleaseLine: async (changeset, type, options = {}) => {+    if (!options.repo) {       throw new Error(         'Please provide a repo to this changelog generator like this:\n"changelog": ["@changesets/changelog-github", { "repo": "org/repo" }]'       );     }++    const shouldThank = (user: string) => {+      // Handle an array of names to not thank

those comments here don't seem super useful - the code is rather simple and handles its job quite literally, so this seems repetitive for me

BeeeQueue

comment created time in 6 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentatlassian/changesets

Add `doNotThank` option to `@changeset/changelog-github`

 const changelogFunctions: ChangelogFunctions = {         commit: changeset.commit       });       return `\n\n- ${links.commit}${-        links.pull === null ? "" : ` ${links.pull}`+        links.pull == null ? "" : ` ${links.pull}`

IMHO would be better to keep strong comparisons here - ===

BeeeQueue

comment created time in 6 days

Pull request review commentmui-org/material-ui

[Slider] Create unstyled version and migrate to emotion & styled-components

     "typescript": "tslint -p tsconfig.json \"{src,test}/**/*.{spec,d}.{ts,tsx}\" && tsc -p tsconfig.json && tsc -p tsconfig.build.json"   },   "peerDependencies": {+    "@material-ui/styled-engine": "^5.0.0-alpha.1",

@Andarist I have seen react-select have emotion as a direct dependency so does chakra v1: chakra-ui/chakra-ui#615 (comment). What should we have as a peer dependency?

Interesting, wasn't aware that they use emotion as a regular dep. Gonna ask Mitchell about this.

mnajdova

comment created time in 6 days

PullRequestReviewEvent

pull request commentmui-org/material-ui

[Slider] Create unstyled version and migrate to emotion & styled-components

I have looked at emotion integration with Next.js. I don't think that the current setup is OK:

We are aware about this validator reports but this doesn't have any downsides in practice. This strategy is allowing the so-called 0 config SSR because we can just render (and stream the result!) without any extra post processing steps. If you want style elements to be put in <head/> this requires rendering the whole thing first and then parsing the outcome and moving things around so the adjusted output can be shipped to the client. We provide a package for all of this but it becomes way less 0 config if you go that route.

@Andarist are the imports going to change in emotion v11?

Yes, but only a little bit and we provide a codemod for this. Changes are - different pkg name (@emotion/core -> @emotion/react) and what has been previously in emotion-theming package is now exported from @emotion/react. We are close to shipping v11 so I assume this won't affect you much because you will be able to "migrate" before your stuff hits the stable mark, right?

Are you aware of this line?

I assume that this is pretty much equivalent of:

import createCache from '@emotion/cache'
const cache = createCache({ key: 'mui' })
cache.compat = true

The only utilize the builtin cache from emotion that has this flag already set. It's a flag suppressing some warnings that are in place to validate if the rendered styles are compatible with 0 config SSR. If one is not interested in that they can set this flag and we assume that the non-0 config SSR approach will be used by the consumer.

mnajdova

comment created time in 6 days

issue commentatlassian/changesets

Release text

if changesets aren't routinely merged (from the version branch), they'll be overwritten. Right?

Not quite - what is being pushed is always your base branch with changeset version applied to it. So unless you remove something on your base branch you won't "lose" it from the versioning PR either.

the version branch becomes a sort of de-factor primary branch (like, e.g. master), right? Or, vice-versa.

Not quite. Your base branch stays untouched - we only create a branch from it that can be merged to that base branch at any time to trigger the release (assuming you have our action installed on the base branch).

The way I implemented it (there's a tradeoff, of course), is to have the commit to master create a second commit – the result of version.

It sounds like you make a release after each merge to your base branch - which is fine, but it's not something we default to here. As mentioned - the releases don't happen rapidly with each merge to the base branch, but rather can be done at any suitable time by simply merging the versioning PR.

but there's still the problem that two rapid commits to master produce a race-condition. Was wondering if you'd put thought into that and had a workaround.

I thought about race conditions in general regarding this workflow, but haven't encountered them in practice yet.

dfee

comment created time in 6 days

issue commentemotion-js/emotion

This selector does not work, is this intended? `:not(pre) > code`

It works correctly: https://codesandbox.io/s/thirsty-blackburn-75m8i?file=/src/App.js , but I've recognized the problem with the playground. Styles on the playground are processed with our Babel plugin which has a bug and it incorrectly removes this meaningful whitespace. I've fixed it already here but the fix is only available in the upcoming Emotion 11.

You can either upgrade to Emotion 11 which is super stable and already used in production at scale - we only have a single issue to solve before we release RC. Or you can trick our Babel plugin by, for example, doing this: Screenshot 2020-09-22 at 08 19 17

kuworking

comment created time in 6 days

pull request commentdavidkpiano/xstate

chore: use tsdx to build @xstate/react

Thanks!

fubhy

comment created time in 6 days

push eventdavidkpiano/xstate

Sebastian Siemssen

commit sha 2fd0ee24dbad8aec69ed2ab003c2e6c1c3f50f1f

Add "module" build for @xstate/react (#1460)

view details

push time in 6 days

PR merged davidkpiano/xstate

chore: use tsdx to build @xstate/react

My original motivation for this pull request was to get @xstate/react to play nicely with Snowpack by just adding an ESM build for this particular package.

While doing so, however, I found that there is a wide range of different build setups for all the packages in this repository and was wondering if it might make sense to unify that setup in one sweeping change instead.

As tsdx is already used in one package and I personally also use this for my own libraries I went with that but am also open for other options.

Would you be open to accepting a pull request that reconfigures the entire repository more broadly to use tsdx throughout instead of typescript project reference builds. I'd also suggest to move the dependencies to each package individually as well as the jest runtime and then use lerna to invoke all these runtimes (build, test, lint, etc.) on a per-package basis. There are also mixtures of yarn and npm sprinkled here and there - Not sure which one you'd prefer but even with the latest improvements to npm my experience with monorepos is in favor of yarn).

Let me know if you think this would be out of scope for now or if I should proceed. For my own personal use, this pull request alone gets the job done.

@davidkpiano Btw. I don't know if you remember but we met at the first Agent Conf in Austria as speakers (I co-presented with Nik Graf) and went skiing together afterwards. We both ended up on the newbie squad and rolled down the mountain more than anything else :-D

+5 -2

8 comments

1 changed file

fubhy

pr closed time in 6 days

pull request commentspotify/backstage

Introducing Changeset workflow

The only gap left to fill is creating pre-release distributions for Version Packages PRs. We punted on this, but it would be very helpful to auto publish the latest state of Version Packages PR branch.

The mentioned snapshots releases could help you with that. You could release those on each commit there.

taras

comment created time in 6 days

pull request commentspotify/backstage

Introducing Changeset workflow

You'd only have to remember to bring back ^ when exiting the prerelease mode (assuming that it's what you want for regular releases). This is a bummer and easy to miss - therefore we were thinking about converting project to exact deps, but keeping info about specified range modificators so they could be brought back when exiting the prerelease mode. It's not super high on our priority list though, so I don't know if we implement this any soon. We were also thinking about slightly alternative way of doing prereleases - leveraging existing snapshots releases, just tailoring it a little bit to allow for somewhat regular release workflow. This would possibly solve many edge cases around existing prerelease mode by just removing a lot of complexity, statefulness etc. Either way - this also was just a random talk last week, but maybe we'll act on it some time in the future.

Bottom line is - versioning is hard, but the changesets concept is very solid (imho) 😅

taras

comment created time in 7 days

pull request commentmattpocock/xstate-codegen

Allowed for aliasing services to serviceName.onDone and serviceName.onError

I will just copy-paste my arguments against this from the Slack, so it's all kept in the single place here:

  • it maps the rather simply convention to just a slightly shorter one -> arguable gain
  • 2x ways of doing the same thing -> we know how this ends in teams
  • it suddenly allows for on: { 'makeFetch.onDone': someTarget }

I think that especially the 3rd one is strong (1st one is subjective, but quite strong for me 😅 ).

I partially agree - we're really just adding an alias from done.invoke.serviceName to serviceName.onDone. This is potentially confusing.

This is confusing also because one won't ever receive such a declared event but yet can receive the original one. So this might come as a surprise for somebody when debugging etc.

Possibly, but only if the service is declared either inline, or in the second parameter of Machine/createMachine.

Actually, that's not quite true... @mwarger had an idea about how this could be achieved in its current form. The proposed solution imposes some constraints on the user, but given the understandable pushback regarding only allowing all-in-one-place machine definitions maybe it's the way to go? To the point though. @mwarger has suggested to crawl the whole project in the search of references to the created machine, grab types from there, and fill the gaps at the definition site. We have much more freedom with the approach of having a tool to do the codegen/typegen stuff than when when only can rely on TS builtin inference. One caveat of the proposed solution is to restrict consuming sites to 1 because if one provides more than one set of some stuff at different consuming sites then I'm really not sure how to generate stuff reliably. The complexity of this doesn't sound justified at all - even if we could figure something out. Alternatively we could allow for multiple consuming sites but we'd have to validate if they provide functions with the same signature etc.

mattpocock

comment created time in 7 days

issue commentredux-saga/redux-saga

Assigning the result to variable when yield another generator function

It works in the context of saga because iterators are recognized as valid yielded values that are being interpreted by our runtime. So just how we interpret yielded fork/call/whatever effects we are capable of interpreting iterators - which you have yielded to use here yield userInfo(). And as we handle this on our own - we can do whatever we want 😉 yield userInfo() is basically interpreted in the very same way as yield call(userInfo).

zanfirandra

comment created time in 7 days

pull request commentspotify/backstage

Introducing Changeset workflow

If we want patch to increase everything across the board, then we should remove "^" from versions if we're expecting to be using prereleases for a while.

Right - the strategy to skip publishing when a dependency is still in range is OK for regular releases but we've found out that it't not so good for prereleases because they don't really have the same conceptual guarantee that 0.1.1-alpha.23 is a safe replacement for 0.1.1-alpha.22. Prereleases are all about experimentation so we kinda think that anything beyond strict dependency ranges (dropping all modificators like ^) lends itself to be unsafe for the end consumers. We are thinking how to best remedy this in Changesets.

taras

comment created time in 7 days

pull request commentspotify/backstage

Introducing Changeset workflow

@taras sure, but I thought the point of linked packages was they were all gonna be updated together? ^_>

That would be "fixed" versioning. The concept of linked packages is slightly more complicated - it only ensures that packages in the set will get the highest version among the set when being released. The classification for the release itself doesn't change.

So instead of always bumping all packages in the set we try to minimize necessary releases.

I've been talking with Mitchell about some alternatives just last week (not for how linked works, but rather for how we sometimes bump dependant packages and how we sometimes dont) - if this doesn't satisfy your requirements then let's talk to try figure out some common ground.

taras

comment created time in 7 days

Pull request review commentmui-org/material-ui

[Slider] Create unstyled version and migrate to emotion & styled-components

   },   "dependencies": {     "@babel/runtime": "^7.4.4",+    "@material-ui/styled-engine": "^5.0.0-alpha.1",

I can only confirm - peer deps requirements spread across the dependency chain :/ in this case what is a peer dep of @material-ui/styled-engine should be a peer dep of the package that depends on @material-ui/styled-engine

mnajdova

comment created time in 7 days

PullRequestReviewEvent

PR closed emotion-js/emotion

Bump http-proxy from 1.16.2 to 1.18.1 in /playgrounds/razzle dependencies

Bumps http-proxy from 1.16.2 to 1.18.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/http-party/node-http-proxy/releases">http-proxy's releases</a>.</em></p> <blockquote> <h2>Long overdue maintenance</h2> <p>Due to some great contributions I'm happy to announce a new release of <code>http-proxy</code> containing numerous bug fixes, feature additions and documentation improvements. Thanks to all who contributed for their patience and willingness to contribute despite perceived stagnation in activity in the project. I welcome all contributions and those who are interested in getting more involved with the project. Below I will highlight the changes that landed in the latest version but you can find the full diff of the changes in <a href="https://github-redirect.dependabot.com/nodejitsu/node-http-proxy/pull/1251">nodejitsu/node-http-proxy#1251</a></p> <ul> <li>Add option to rewrite path of set-cookie headers. <a href="https://github.com/swillis12">@swillis12</a></li> <li>Add option for overriding http METHOD when proxying request <a href="https://github.com/AydinChavez">@AydinChavez</a></li> <li>Feature: selfHandleResponse for taking responsibility in returning your own response when listening on the <code>proxyRes</code> event. <a href="https://github.com/cpd0101">@cpd0101</a> <a href="https://github.com/guoxiangyang">@guoxiangyang</a></li> <li>Add <code>followRedirects</code> option <a href="https://github.com/n30n0v">@n30n0v</a></li> <li>Document <code>timeout</code> option <a href="https://github.com/jlaamanen">@jlaamanen</a></li> <li>Fix documentation typos <a href="https://github.com/carpsareokiguess">@carpsareokiguess</a></li> <li>Document <code>buffer</code> option <a href="https://github.com/jonhunter1977">@jonhunter1977</a></li> <li>Include websocket non-upgrade response instead of just closing the socket. Allows auth schemes to be possible with websocket proxying. <a href="https://github.com/Tigge">@Tigge</a></li> <li>Stop using the <code>writeHead</code> method explicitly and let node handle it internally to prevent thrown errors <a href="https://github.com/jakefurler">@jakefurler</a></li> <li>Be more defensive in handling of detecting response state when proxying <a href="https://github.com/thiagobustamante">@thiagobustamante</a></li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/http-party/node-http-proxy/blob/master/CHANGELOG.md">http-proxy's changelog</a>.</em></p> <blockquote> <h2><a href="https://github.com/http-party/node-http-proxy/compare/1.18.0...v1.18.1">v1.18.1</a> - 2020-05-17</h2> <h3>Merged</h3> <ul> <li>Skip sending the proxyReq event when the expect header is present <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1447"><code>#1447</code></a></li> <li>Remove node6 support, add node12 to build <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1397"><code>#1397</code></a></li> </ul> <h2><a href="https://github.com/http-party/node-http-proxy/compare/1.17.0...1.18.0">1.18.0</a> - 2019-09-18</h2> <h3>Merged</h3> <ul> <li>Added in auto-changelog module set to keepachangelog format <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1373"><code>#1373</code></a></li> <li>fix 'Modify Response' readme section to avoid unnecessary array copying <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1300"><code>#1300</code></a></li> <li>Fix incorrect target name for reverse proxy example <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1135"><code>#1135</code></a></li> <li>Fix modify response middleware example <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1139"><code>#1139</code></a></li> <li>[dist] Update dependency async to v3 <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1359"><code>#1359</code></a></li> <li>Fix path to local http-proxy in examples. <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1072"><code>#1072</code></a></li> <li>fix reverse-proxy example require path <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1067"><code>#1067</code></a></li> <li>Update README.md <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/970"><code>#970</code></a></li> <li>[dist] Update dependency request to ~2.88.0 [SECURITY] <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1357"><code>#1357</code></a></li> <li>[dist] Update dependency eventemitter3 to v4 <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1365"><code>#1365</code></a></li> <li>[dist] Update dependency colors to v1 <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1360"><code>#1360</code></a></li> <li>[dist] Update all non-major dependencies <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1356"><code>#1356</code></a></li> <li>[dist] Update dependency agentkeepalive to v4 <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1358"><code>#1358</code></a></li> <li>[dist] Update dependency nyc to v14 <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1367"><code>#1367</code></a></li> <li>[dist] Update dependency concat-stream to v2 <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1363"><code>#1363</code></a></li> <li>x-forwarded-host overwrite for mutli level proxies <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1267"><code>#1267</code></a></li> <li>[refactor doc] Complete rename to http-party org. <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1362"><code>#1362</code></a></li> <li>Highlight correct lines for createProxyServer <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1117"><code>#1117</code></a></li> <li>Fix docs for rewrite options - 201 also handled <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1147"><code>#1147</code></a></li> <li>Update .nyc_output <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1339"><code>#1339</code></a></li> <li>Configure Renovate <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1355"><code>#1355</code></a></li> <li>[examples] Restream body before proxying, support for Content-Type of application/x-www-form-urlencoded <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1264"><code>#1264</code></a></li> </ul> <h3>Commits</h3> <ul> <li>[dist] New test fixtures. <a href="https://github.com/http-party/node-http-proxy/commit/7e4a0e511bc30c059216860153301de2cdd1e97f"><code>7e4a0e5</code></a></li> <li>[dist] End of an era. <a href="https://github.com/http-party/node-http-proxy/commit/a9b09cce43f072db99fb5170030a05536177ccb7"><code>a9b09cc</code></a></li> <li>[dist] Version bump. 1.18.0 <a href="https://github.com/http-party/node-http-proxy/commit/9bbe486c5efcc356fb4d189ef38eee275bbde345"><code>9bbe486</code></a></li> <li>[fix] Latest versions. <a href="https://github.com/http-party/node-http-proxy/commit/59c4403e9dc15ab9b19ee2a3f4aecbfc6c3d94c4"><code>59c4403</code></a></li> <li>[fix test] Update tests. <a href="https://github.com/http-party/node-http-proxy/commit/dd1d08b6319d1def729554446a5b0176978a8dad"><code>dd1d08b</code></a></li> <li>[dist] Update dependency ws to v3 [SECURITY] <a href="https://github.com/http-party/node-http-proxy/commit/b00911c93740a00c5cfbacbb91565cb6912ed255"><code>b00911c</code></a></li> <li>[dist] .gitattributes all the things. <a href="https://github.com/http-party/node-http-proxy/commit/fc93520d741ec80be8ae31ca005f3e9c199e330e"><code>fc93520</code></a></li> <li>[dist] Regenerate package-lock.json. <a href="https://github.com/http-party/node-http-proxy/commit/16d4f8a95162b2e2e4ee6657c500f1208c044b2d"><code>16d4f8a</code></a></li> </ul> <h2><a href="https://github.com/http-party/node-http-proxy/compare/1.16.2...1.17.0">1.17.0</a> - 2018-04-20</h2> <h3>Merged</h3> <ul> <li>Fix overwriting of global options <a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/pull/1074"><code>#1074</code></a></li> </ul> <!-- raw HTML omitted --> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/http-party/node-http-proxy/commit/9b96cd725127a024dabebec6c7ea8c807272223d"><code>9b96cd7</code></a> 1.18.1</li> <li><a href="https://github.com/http-party/node-http-proxy/commit/335aeeba2f0c286dc89c402eeb76af47834c89a3"><code>335aeeb</code></a> Skip sending the proxyReq event when the expect header is present (<a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/issues/1447">#1447</a>)</li> <li><a href="https://github.com/http-party/node-http-proxy/commit/dba39668ba4c9ad461316e834b2d64b77e1ca88e"><code>dba3966</code></a> Remove node6 support, add node12 to build (<a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/issues/1397">#1397</a>)</li> <li><a href="https://github.com/http-party/node-http-proxy/commit/9bbe486c5efcc356fb4d189ef38eee275bbde345"><code>9bbe486</code></a> [dist] Version bump. 1.18.0</li> <li><a href="https://github.com/http-party/node-http-proxy/commit/6e4bef4d1cd96e7a284717941e0fc274acbd3712"><code>6e4bef4</code></a> Added in auto-changelog module set to keepachangelog format (<a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/issues/1373">#1373</a>)</li> <li><a href="https://github.com/http-party/node-http-proxy/commit/d05624167ce75e860770c13afeacec2ce0f67add"><code>d056241</code></a> fix 'Modify Response' readme section to avoid unnecessary array copying (<a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/issues/1300">#1300</a>)</li> <li><a href="https://github.com/http-party/node-http-proxy/commit/244303b994525684e1ec8dff2e8055f89b62b1ee"><code>244303b</code></a> Fix incorrect target name for reverse proxy example (<a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/issues/1135">#1135</a>)</li> <li><a href="https://github.com/http-party/node-http-proxy/commit/b4028ba78bc4616e6969e0e66b0fe4634849b68b"><code>b4028ba</code></a> Fix modify response middleware example (<a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/issues/1139">#1139</a>)</li> <li><a href="https://github.com/http-party/node-http-proxy/commit/77a98159d2da0f20a03e2819c79662f36069f234"><code>77a9815</code></a> [dist] Update dependency async to v3 (<a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/issues/1359">#1359</a>)</li> <li><a href="https://github.com/http-party/node-http-proxy/commit/c662f9ebcd8d623db374dbc7bef231b2b0af0c3a"><code>c662f9e</code></a> Fix path to local http-proxy in examples. (<a href="https://github-redirect.dependabot.com/http-party/node-http-proxy/issues/1072">#1072</a>)</li> <li>Additional commits viewable in <a href="https://github.com/http-party/node-http-proxy/compare/1.16.2...1.18.1">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+5152 -991

2 comments

1 changed file

dependabot[bot]

pr closed time in 7 days

pull request commentspotify/backstage

Introducing Changeset workflow

Played around with this a bit, and as far as I can tell the package linking doesn't work with prereleases. Is that something that should work @Andarist?

It should work - we are using it in Emotion and I haven't found any particular problems with that. If you point me to commits on which you have observed things not working correctly I could take a look at it.

taras

comment created time in 7 days

issue commentatlassian/changesets

Release text

Why do your releases have notes attached, but if we don't use the action, no note is attached.

They are created by the action: https://github.com/changesets/action/blob/bfeb9e077e6cf393e4c4ef17e2bbc75b308b4364/src/run.ts#L35-L40

I think that the Action you've provided (the one which does a force push to a branch: version, is a smelly anti-pattern.

Everything has someplace in the world 😉 In this particular example we feel that this is the right way to handle this - causing less friction for the users and without many downsides. The versioning PRs that our action creates is supposed to represent a single commit, a single point in time - it syncs to what happens to your base branch.

dfee

comment created time in 7 days

more