profile
viewpoint
Borek Bernard borekb @versionpress Prague, Czech Republic https://twitter.com/borekb Developer at @versionpress

borekb/apollo-typescript-example 17

Apollo Client 2.0 + TypeScript example

borekb/docker-path-workaround 17

Path conversion workaround for Docker on Windows & Git Bash / MSYS2

borekb/agkozak-zsh-theme 2

An asynchronous ZSH prompt with color ASCII indicators of Git, exit, SSH, and vi mode status. Framework-agnostic.

borekb/cs-en-dictionary 2

Spell checking dictionary for Firefox combining cs and en-US

borekb/coffee-script-tmbundle 1

A TextMate Bundle for CoffeeScript

borekb/darker-plus-theme 1

Darker+ theme for VSCode

borekb/dokuwiki 1

The DokuWiki Open Source Wiki Engine

borekb/apollo 0

:rocket: Open source tools for GraphQL. Central repo for discussion.

borekb/apollo-server 0

🌍 GraphQL server for Express, Connect, Hapi, Koa and more

borekb/auth0-PHP 0

Auth0-PHP SDK

delete branch versionpress/versionpress

delete branch : 1481-vp-status

delete time in 2 days

push eventversionpress/versionpress

Borek Bernard

commit sha dc378a72136d1260144f6988283492448f54d09d

Add note about inactive development to README

view details

Borek Bernard

commit sha 0c5378ea5fa1f04a59e89b86947bf19f37089157

Merge pull request #1491 from versionpress/1481-vp-status Add note about inactive development to README

view details

push time in 2 days

PR merged versionpress/versionpress

Add note about inactive development to README

Issue: #1481

Adds a note to README about inactive development, points to issue #1481 where more is explained.

+6 -0

0 comment

1 changed file

borekb

pr closed time in 2 days

PR opened versionpress/versionpress

Add note about inactive development to README

Issue: #1481

Adds a note to README about inactive development, points to issue #1481 where more is explained.

+6 -0

0 comment

1 changed file

pr created time in 2 days

create barnchversionpress/versionpress

branch : 1481-vp-status

created branch time in 2 days

issue openedbartosz-antosik/vscode-spellright

Write to LocalDictionary on macOS

"Add ... to user dictionary" seems to be using language-specific files, e.g., a file called en:

~/Library/Spelling/en

The Notes app, as well as a few other apps I've tried, seem to be writing to a file called LocalDictionary:

~/Library/Spelling/LocalDictionary

I think it would be cleaner if Spell Right used this file as well (I have words across many files, like it or fr or es; not sure why as I only use English and Czech as the languages on my Mac).

created time in 2 days

issue commentsamuelmeuli/tmignore

Homebrew install fails

I'm also getting the "sandbox-exec: sandbox_apply: Operation not permitted" error. I'm on macOS 10.15.17 and XCode 12.0.1.

BTW, I had to download the full XCode, command line tools were not enough. (Unfortunately, I didn't copy the error message.)

@samuelmeuli With the pre-built binaries, future upgrades won't work, right? Also, brew services start tmignore also won't be available I guess?!

fuerst

comment created time in 2 days

issue openedyarnpkg/berry

[Bug] @types packages are not resolved by VSCode TypeScript pnpify SDK

We have a monorepo where the root contains only dev dependencies like Prettier, and it uses PnP.

Then we have several projects in subfolders, like app1, app2, etc. Some of them are on Yarn 1, some on Yarn 2, but they all use the node-modules linker.

It all looks like this:

.
├── package.json
├── yarn.lock
├── .yarnrc.yml
├── .pnp.js
├── app1/
│   ├── package.json
│   ├── yarn.lock
│   ├── node_modules
│   └── .yarnrc.yml
└── app2/
    ├── package.json
    ├── yarn.lock
    ├── node_modules
    └── .yarnrc.yml

We've ran yarn dlx @yarnpkg/pnpify --sdk vscode which made most of the things work, however, TypeScript doesn't understand imports that depend on @types/... packages:

Screen Shot 2020-09-23 at 18 15 46-shadow

mobx-react and formstate contain .d.ts files so everything work fine, but react, next/router and @apollo/client depend on @types packages and those don't work.

This is our root .yarnrc.yml – I believe it is configured correctly:

yarnPath: '.yarn/releases/yarn-2.2.2.cjs'
pnpIgnorePatterns:
  - 'app1/**'
  - 'app2/**'

Environment:

  • OS: macOS
  • Node version: 12
  • Yarn version: 2.2.2.

created time in 6 days

issue commentcareteditor/issues

Has development stopped?

I switched to a new machine, went to https://github.com/notaapp/releases/releases, the current one is 0.15.0, there's only a single big file in the assets section:

Screen Shot 2020-09-23 at 14 37 17

so I downloaded that and then ended up in the same situation as @devisions. I then tried the same with 0.14.0 which has the same problem. Only the 0.13.1 version seems to have the DMG file attached.

faldor20

comment created time in 7 days

issue commentcareteditor/issues

Has development stopped?

I had the same problem – the 0.15 release doesn't contain the DMG; I had to download the 0.13.1 release (make sure to get the Nota-0.13.1.dmg file, not the ZIP!) and then let Nota auto-update itself to 0.15.

Spent like 15 minutes banging my head against the wall 😄.

faldor20

comment created time in 7 days

issue openednotaapp/issues

Expand selection in links – small issue

✅ Correct sequence of cmd-e when I start from the URL part:

Screenshot 2020-09-16 at 09 20 35

Screenshot 2020-09-16 at 09 21 13

Screenshot 2020-09-16 at 09 20 59

Screenshot 2020-09-16 at 09 21 29

Screenshot 2020-09-16 at 09 21 39


❌ Incorrect sequence of cmd-e when I start from the text part:

Screenshot 2020-09-16 at 09 23 26

Screenshot 2020-09-16 at 09 23 37

Screenshot 2020-09-16 at 09 23 48

[The fourth step is missing]

Screenshot 2020-09-16 at 09 23 56

created time in 14 days

issue commentmartpie/next-transpile-modules

Pnp workspaces aren't transpiled (yarn berry)

Using a specific path seems to work for us:

- withTM(['@scope/lib']
+ withTM(['../lib']

It's uglier but works.

goszczynskip

comment created time in 15 days

issue commentgetantibody/antibody

Static loading produces empty file

In my case, my mistake was that I removed source <(antibody init) from .zshrc and ran source ~/.zshrc – I was also seeing empty .zsh_plugins.sh after that.

The "start a fresh terminal session" in the docs is important. After doing so, everything worked fine.

marlonrichert

comment created time in 19 days

delete branch borekb/yarn-install-demo

delete branch : temp

delete time in 19 days

delete branch borekb/yarn-install-demo

delete branch : add-nextjs-code

delete time in 19 days

push eventborekb/yarn-install-demo

Borek Bernard

commit sha 431e0c436c371ba217f7a1ddbb4188c73d4c5aa0

Add Next.js source code to demonstrate build

view details

Borek Bernard

commit sha 38373e4d35a0be7949ba3761914626243909d652

Merge pull request #4 from borekb/add-nextjs-code Add Next.js source code to demonstrate build

view details

push time in 19 days

create barnchborekb/yarn-install-demo

branch : add-nextjs-code

created branch time in 19 days

push eventborekb/yarn-install-demo

Borek Bernard

commit sha 2ac092354b33a25b153854c9a93c5e1a3f2ff319

Rename scope ... to create the same alphabetical order that we have in a company repo.

view details

push time in 20 days

PR closed borekb/yarn-install-demo

Temp

Some more experiments.

WIP

+147 -138

0 comment

7 changed files

borekb

pr closed time in 20 days

PR opened vercel/next.js

Reviewers
Ignore .next also in subfolders

As the example is about Yarn workspaces, it should gitignore .next recursively.

+1 -2

0 comment

1 changed file

pr created time in 21 days

push eventborekb/next.js

Borek Bernard

commit sha 42705b9949c8c9f090783a006ce5910593204008

Ignore .next also in subfolders

view details

push time in 21 days

create barnchborekb/yarn-workspaces-next-build-demo

branch : master

created branch time in 21 days

created repositoryborekb/yarn-workspaces-next-build-demo

created time in 21 days

issue commentyarnpkg/berry

[Bug] `yarn set version` modifies .yarnrc.yml unnecessarily

@paul-soporan I just came to search the issues after Yarn deleted my comments from .yarnrc.yml file (which made a bit angry to be honest 😄; I hate when tools silently drop my data) so it's great to see your thoughtful comment above.

I'll just say a few things:

  • Reordering .yarnrc.yml is unpleasant. In fact, we usually run a command like yarn set version, then copy the relevant line, revert the whole file and re-add manually. Doesn't feel right.
  • Data loss is plan unacceptable, IMO.
  • Bundle size wouldn't be a problem if the binary wasn't committed to a Git repo – I guess we're waiting for #969 or pmm so generally yeah, you probably need to worry about bundle size and make difficult tradeoffs.
bertho-zero

comment created time in 22 days

issue commentp0deje/Maccy

First impressions of a new user

Thanks for your replies. Just quickly:

  • cmd-shift-v is often used by apps for "paste without formatting", e.g., Google Docs. cmd-alt-v is safer.
  • About the pinned items: most clipboard managers have separate sections for them, which makes the most sense to me.
  • Dealing with lots of items: there are several ways to do it, e.g., you can visually suggest that there are more items (e.g. add a "scroll to see more" menu item) or use nesting.

Here's Clipy's UI for reference – not saying it's ideal but it shows that there are ways to deal with long lists / performance / UI complexity.

Screenshot 2020-09-08 at 09 44 21

As for the bug (Maccy stops recording history), I think it happens after I paste my pinned item via a keyboard shortcut (cmd-m in my case). I'll keep watching it and post a separate issue if I can reliably reproduce this.

borekb

comment created time in 22 days

issue openedyarnpkg/berry

[Bug] Link step's progress bar can spike CPU and slow down install significantly

Describe the bug

The link step uses a CLI spinner that looks like ora (not sure what exactly is used) and it seems it's causing high CPU usage of iTerm2 in some situations, leading to slow install times.

Screenshot 2020-09-03 at 11 53 17-shadow

The slowdown is serious – in the yarn-install-demo repo, I'm seeing times of ~40 seconds in the "lucky" case (CPU usage of iTerm stays low) and over 4 minutes in the unlucky one, completely overwhelming my system.

Running yarn | cat or CI=true yarn consistently produces install times of around 40 seconds on my system (always after removing all node_modules from the project).

Related Discord discussion starts around here and spinner identified as a likely cause around here.

To Reproduce

This issue doesn't have a clear repro, unfortunately. My best guess is that it somehow related to the "oldness" of a terminal session in iTerm – old sessions seem to be more prone to this compared to fresh ones; sometimes, restarting iTerm or the whole system seems to help (but not always).

The slowness has also been observed by my colleague @JanVoracek (who uses MBP 2015 & macOS Catalina) and @merceyz (see Discord).

Environment if relevant (please complete the following information):

  • OS: macOS 10.15.6 Catalina
  • Node version: 12.14.0
  • Yarn version: 2.2.0

created time in 23 days

issue openedp0deje/Maccy

First impressions of a new user

Hi, I'm trying Maccy after using Clipy on macOS and ClipX on Windows (a long time ago), wanted to post first impressions. It probably doesn't fit the usual issue in this repo so sorry if this is not appropriate but my hope is that some of the feedback would be useful.

  • Maccy is lightweight and contains search. Awesome! ❤️
  • Some defaults felt weird to me:
    • Why "C" (cmd-shift-c) for paste? I personally prefer cmd-alt-v but anything with "V" it in would feel more natural.
    • Enter doesn't paste – why?
    • Pinned items should be at the bottom by default, IMO, as the primary use case of the app is interacting with clipboard history, not pinned items.
    • Taking up the entire monitor height didn't feel very nice – limited "visible items" to something like 20 made it better.
  • I'd expect pinned items to be "numbered" A, B, C etc. so that e.g. pasting the 2nd pinned item is always cmd-shift-vcmd-b (or cmd-shift-vbEnter).
  • Selecting 2nd item by default is a nice little touch in ClipX – since the first item is in system clipboard, the most likely item I'm going for to the clipboard manager is on the 2nd position.
  • I've encountered several bugs during the past 3 days like image previews not being rendered correctly after scrolling. Probably the most annoying was when Maccy stopped recording clipboard history for some reason – that's almost a "data loss" since I depend on clipboard manager so heavily 😄.

In summary, I love the direction of the app, think the defaults could be better and there's some work around stability/reliability. But very nice overall 👍.

created time in 23 days

issue openedsamuelmeuli/tmignore

node_modules being backed up despite being tmignored (?)

I've been using tmignore happily in the past, it always worked well but in the recent backup, I see several node_modules using the BackupLoupe utility:

Screenshot 2020-09-06 at 15 03 00

The yarn-install-demo is actually this public repo: https://github.com/borekb/yarn-install-demo where you can see two .gitignore files:

I did a quick tmignore check which looks alright:

$ tmignore list | rg 'yarn-install-demo'
  - /Users/borekb/dev/borekb/yarn-install-demo/packages-v1/app/node_modules/
  - /Users/borekb/dev/borekb/yarn-install-demo/packages-v1/lib/node_modules/
  - /Users/borekb/dev/borekb/yarn-install-demo/packages-v1/node_modules/
  - /Users/borekb/dev/borekb/yarn-install-demo/packages-v2/.yarn/build-state.yml
  - /Users/borekb/dev/borekb/yarn-install-demo/packages-v2/.yarn/cache/
  - /Users/borekb/dev/borekb/yarn-install-demo/packages-v2/.yarn/install-state.gz
  - /Users/borekb/dev/borekb/yarn-install-demo/packages-v2/app/node_modules/
  - /Users/borekb/dev/borekb/yarn-install-demo/packages-v2/lib/node_modules/
  - /Users/borekb/dev/borekb/yarn-install-demo/packages-v2/node_modules/

How comes that .yarn cache files are excluded from the backup but node_modules aren't? I also ran this, which again contained only .yarn/* entries and no node_modules entries:

$ find /Users/borekb/dev/borekb/yarn-install-demo -exec tmutil isexcluded {} + | grep -F "[Excluded]" | sed -E 's/^\[Excluded\][[:space:]]*//'
/System/Volumes/Data/Users/borekb/dev/borekb/yarn-install-demo/packages-v2/.yarn/cache
/System/Volumes/Data/Users/borekb/dev/borekb/yarn-install-demo/packages-v2/.yarn/cache/fb-watchman-npm-2.0.0-98fd97d6b7-192298457e.zip
/System/Volumes/Data/Users/borekb/dev/borekb/yarn-install-demo/packages-v2/.yarn/cache/elegant-spinner-npm-1.0.1-8b799f39a6-69837a8a88.zip
...

(The yarn-install-demo folder on my disk is about 3 days old while the Time Machine backup was run 1 hour ago, so there shouldn't be any problem with the node_modules folder not being known to tmignore yet.)

Any ideas?

created time in 24 days

issue commentremy/jqterm

Where is the data stored?

Yes, I can. I see my JSON on gist.github.com and there's no way for me to delete it, right?

borekb

comment created time in a month

issue commentremy/jqterm

Where is the data stored?

You're right, my sentence "most online playgrounds / editors don't share user data by default" should have used the word store instead of share. Other than that, what do you think about making this more explicit / user-controlled? My data ended up on GitHub's servers as plain text, accessible via URL. This was sort of unexpected.

borekb

comment created time in a month

issue commentremy/jqterm

Where is the data stored?

Thanks for the clarification.

Would you consider putting this functionality behind an explicit action like a "share" button, or at least making it clear that anything pasted to jqterm.com is uploaded to a 3rd party service in a plain text format? I understand that pasting text into any website is inherently risky but most online playgrounds / editors don't share user data by default, or at least have privacy policies that explain how user data is treated and which other third parties have access to them.

(To be clear, technically, I understand that it is unlikely / close to impossible to guess the Gist's ID and hence "leak" user data.)

borekb

comment created time in a month

issue commentremy/jqterm

Where is the data stored?

I'm not sure which Gist. I just visited jqterm.com, entered a JSON and a query and got a URL like this back:

https://jqterm.com/2d6d6....?query=...

This URL worked also in a different browser so I guess my JSON is persisted somewhere. I didn't authenticate with my GitHub account so there is no new Gist in my account (obviously).

borekb

comment created time in a month

issue openedremy/jqterm

Where is the data stored?

Hi, a really neat service! I'm wondering, where is the data stored / persisted? Some sort of database? Is it encrypted or plain text? Thanks!

created time in a month

fork borekb/berry

📦🐈 Active development trunk for Yarn 2+ ⚒

https://yarnpkg.com

fork in a month

PR opened borekb/yarn-install-demo

Temp

Some more experiments.

WIP

+147 -138

0 comment

7 changed files

pr created time in a month

create barnchborekb/yarn-install-demo

branch : temp

created branch time in a month

push eventborekb/yarn-install-demo

Borek Bernard

commit sha fd501ae11ec567cb89a0d12fd1e471dc35bdc8b8

Update README

view details

push time in a month

MemberEvent

delete branch borekb/yarn-install-demo

delete branch : equivalent-v1-lockfile

delete time in a month

push eventborekb/yarn-install-demo

Borek Bernard

commit sha b81a66d152a724f3eb5a75abf47ac7b7f2314f84

Use an equivalent lockfile for v1 This dramatically affects times for the v1 install, increasing it from 25s to 60s. (The v2 install is ~40s.)

view details

Borek Bernard

commit sha 71f8fd7b8177d9f87486e1726deaba4ef50a097a

Merge pull request #2 from borekb/equivalent-v1-lockfile Use an equivalent lockfile for v1

view details

push time in a month

PR merged borekb/yarn-install-demo

Use an equivalent lockfile for v1

This dramatically affects times for the v1 install, increasing it from 25s to 60s. This makes Yarn 2 installs faster as it is around 40s on my machine.


The issue was that originally, the packages-v1 folder was created as a copy of packages-v2 and running yarn in it to "downgrade" the yarn.lock file to v1. However, Yarn doesn't downgrade formats – it basically recreated yarn.lock freshly, which lead to a much simpler install structure. That made the comparison unfair.

It was spotted by @larixer – thanks a lot! See Discord chat.

+6230 -2282

0 comment

2 changed files

borekb

pr closed time in a month

PR opened borekb/yarn-install-demo

Use an equivalent lockfile for v1

This dramatically affects times for the v1 install, increasing it from 25s to 60s. This makes Yarn 2 installs faster as it is around 40s on my machine.


The issue was that originally, the packages-v1 folder was created as a copy of packages-v2 and running yarn in it to "downgrade" the yarn.lock file to v1. However, Yarn doesn't downgrade formats – it basically recreated yarn.lock freshly, which lead to a much simpler install structure. That made the comparison unfair.

It was spotted by @larixer – thanks a lot! See Discord chat.

+6230 -2282

0 comment

2 changed files

pr created time in a month

create barnchborekb/yarn-install-demo

branch : equivalent-v1-lockfile

created branch time in a month

delete branch borekb/yarn-install-demo

delete branch : prepare-demo

delete time in a month

push eventborekb/yarn-install-demo

Borek Bernard

commit sha b4b1ac9cba15509aec92c2429c363e702824bb01

Add packages-v1

view details

Borek Bernard

commit sha 0d9286799428ac9f5d52768351f18cb24b7216e7

Add packages-v2

view details

Borek Bernard

commit sha c14389b7dbbeff104577a0d3ac99a5d32bfb0082

Write README

view details

Borek Bernard

commit sha bf9817c2fe5e8740debbf699962b965c3b8e40aa

Merge pull request #1 from borekb/prepare-demo Prepare demo

view details

push time in a month

PR merged borekb/yarn-install-demo

Prepare demo

Add packages-v1, packages-v2 and compare them. From the README:


Install packages-v1:

# Initial, slow installation with a cold cache
cd packages-v1
yarn

# Remove node_modules recursively
find . -name 'node_modules' -type d -prune -exec rm -rf '{}' +

# Install again with warm cache
yarn

Then do the same in packages-v2.

The times I'm seeing are:

  • packages-v1: ~25 seconds
  • packages-v1: ~40 seconds

There are also significant differences in the sizes of node_modules installed, and their count:

Screenshot 2020-09-02 at 22 54 47

What is also quite common is that the v2 installs contain nested node_modules where v1 don't:

Screenshot 2020-09-02 at 22 57 55

My guess is that it's somehow related to a more reliable implementation of Yarn 2 n_m linker but it's just a guess.

+40053 -1

0 comment

13 changed files

borekb

pr closed time in a month

PR opened borekb/yarn-install-demo

Prepare demo

Add packages-v1, packages-v2 and compare them. README written.

+40053 -1

0 comment

13 changed files

pr created time in a month

create barnchborekb/yarn-install-demo

branch : prepare-demo

created branch time in a month

create barnchborekb/yarn-install-demo

branch : master

created branch time in a month

created repositoryborekb/yarn-install-demo

created time in a month

issue commentremarkjs/remark-github

Changes indentation within lists

Thanks, adding this was indeed it:

  .use(stringify, {
    listItemIndent: '1'
  })
borekb

comment created time in a month

issue openedremarkjs/remark-github

Changes indentation within lists

I have this script:

#!/usr/bin/env node

const fs = require('fs');
const remark = require('remark');
const github = require('remark-github');

remark()
  .use(github, {
    repository: 'my/repo'
  })
  .process(fs.readFileSync('my-file.md', { encoding: 'utf8' }), function (err, file) {
    if (err) throw err;
    process.stdout.write(String(file));
  });

function throwError(message) {
  throw new Error(message);
}

This is the input:

- #123
- #456

This is the output:

-    [#123](https://github.com/my/repo/issues/123)
-    [#456](https://github.com/my/repo/issues/456)

It added spaces between the - and the issue reference. Is that a misconfiguration on my part or a bug?

created time in a month

issue openedsindresorhus/linkify-issues

Render Markdown (`type: markdown`)

Would be nice if #123 could produce [#123](https://github.com/owner/repo/issues/123).

created time in a month

issue commentaugmentable-dev/askgit

Took very long time on the first run

Unfortunately, it's now a lot slower, for example, that count(*) now takes over 22 seconds (was below 5 seconds previously).

To make sure I'm running the correct image version, I did this:

$ docker run --rm -v `pwd`:/repo:ro docker.io/augmentable/askgit@sha256:ba3c27c17e07a945bc8ac2eb8627975b7d7eb382e19029facb0b0632a1823c2f "SELECT count(*) FROM commits"
borekb

comment created time in a month

issue commentaugmentable-dev/askgit

Took very long time on the first run

Thanks for looking into it.

Is the repo you are running the queries on particular large? In terms of commit count?

Nope:

$ docker run --rm -v `pwd`:/repo:ro augmentable/askgit "SELECT count(*) FROM commits"
+----------+
| COUNT(*) |
+----------+
|     3127 |
+----------+
borekb

comment created time in a month

issue openedaugmentable-dev/askgit

Took very long time on the first run

Is it expected that the basic command from README is so heavy? I initially thought that there's something wrong with my invocation, I did this:

docker run --rm -v `pwd`:/repo:ro augmentable/askgit "SELECT * FROM commits"

Then my computer just seemed to be stuck. I was seeing resource usage like this for over a minute:

Screenshot 2020-08-30 at 10 02 57

Then it eventually finished after about 2.5 minutes but I was seriously worried that I'm doing something wrong, e.g., not escaping the SQL query correctly.

What does it do on the first run? Is it building some sort of database behind the scenes? Would even "simpler" queries like SELECT count(*) FROM commits take similarly long?

created time in a month

issue commentWorldBrain/Memex

Option to disable a toolbar

Ah ok! I thought that Sidebar is that wider panel while Toolbar is the small floating panel, and that the setting only applies to the Sidebar, not Toolbar.

I've got that "Disable sidebar" enabled so I guess I'm one of those people hit by that bug – it's true that I don't see the Toolbar on every page but sometimes, I do.

borekb

comment created time in a month

issue openedWorldBrain/Memex

Option to disable a toolbar

Is there a way to prevent the Toolbar (this small floating thing) to ever appearing at the right of the screen? It interferes with some websites I use and I generally don't need it. Is there a way to make it hide permanently? If not, would you be open to adding a setting for it?

created time in a month

issue commentnotaapp/issues

Incorrect preview for code block

Somehow, the "md" specifier is the problem, both of these are previewed correctly:

```txt
_Search terms: X, Y, Z_
```
```
_Search terms: X, Y, Z_
```
borekb

comment created time in a month

issue openednotaapp/issues

Incorrect preview for code block

This Markdown:

```md
_Search terms: X, Y, Z_
```

is previewed as:

Screenshot 2020-08-18 at 09 35 29

Correct preview would be:

Screenshot 2020-08-18 at 09 36 16

created time in a month

issue commentDavidAnson/markdownlint-cli2

Unintuitive handling of .markdownlintignore files

Since I believe ignore files would be the best UX, I tried to do another search for packages that would be able to do it. My conclusion:

  • Most packages simply don't handle .ignore files in a performant way.
  • Those that pride themselves on speed are often wrappers around ripgrep or fd, like https://www.npmjs.com/package/fast-replace.
  • https://www.npmjs.com/package/ignore-walk seems promising – at least it seems to do the right thing. Not sure about its performance or how to combine it with globs but it's probably the most promising package I've encountered.
  • https://www.npmjs.com/package/deglob combines globs and .gitignore support but probably doesn't support hierarchical ignore files.
  • https://www.npmjs.com/package/glob-gitignore specifically focuses on performance, see their Why section, but it doesn't seem to support ignore files, just gitignore-like array of patterns.

So nothing directly usable, I think.

I was also thinking about making fd/ripgrep opt-in, like markdonwlint-cli2 --use-fd, which would have this binary file dependency but be 1000x faster in return. The trouble is, probably, that to make the base cli2 reasonably fast, you'll need to invent your own performant way to ignore files, like the ignoreGlobs in .markdownlint-cli2.jsonc you mentioned, and this will be inherently incompatible with ignore-based tools.

borekb

comment created time in a month

issue commentmicrosoft/vscode

Allow settings sync history to be exported

Would be great to have this!

I don't know how the service stores the data but I'd like to suggest that a Git repo is considered as an export format – it is a natural and efficient format for versioned data.

Tyriar

comment created time in 2 months

issue commentDavidAnson/markdownlint-cli2

What does `markdownlint-cli2 .` do?

Thanks for confirming that, I though I might just not have enough patience 😀.

However, is that technically correct? I think that the dot glob shouldn't match almost anything – maybe the current directory but certainly not thousands of files, right? At least e.g. fd -g '.' . finishes immediately and doesn't find anything.

Maybe you could detect if there's at least one *.md pattern in the globs and print a warning if not. For example:

$ markdownlint-cli2 .
WARN: No files were linted, please specify a glob like "**/*.md".
borekb

comment created time in 2 months

issue commentDavidAnson/markdownlint-cli2

Support hierarchical `.markdownlintignore` files

Thanks, the issue link should be #1 (this comment specifically) I believe.

borekb

comment created time in 2 months

issue commentDavidAnson/markdownlint-cli2

Unintuitive handling of .markdownlintignore files

The ignore configuration can't (currently) be in one of the config files like you suggest because those files are only found and parsed as part of the command-line globbing (and it's too late to start ignoring then).

That makes sense, thanks for the explanation.

Regarding your timings, the current implementation of markdownlint-cli2 is fast, also!

cli2 is fast and I love that but achieves it by explicit globbing. My point was that fd can be equally fast while respecting the hierarchy of .gitignore files, which is a much harder problem.

I can definitely name the ignore file something like .markdownlint-cli2-extra-globs

I'd probably vote for that but it's a bit ugly and "proper" ignore support would be better, which leads me to:

[...] but I don't yet see how to change the implementation.

I also don't know if there's a Node.js module that would process ignore files and be fast at the same time 😀. For example, globby suffers from exactly the same problem: https://github.com/sindresorhus/globby/issues/50#issuecomment-467897064.

We once needed to find project.json files in a monorepo quickly (this also needs to avoid many such instances in node_modules) and I think we used vscode-ripgrep for that – it's a package that downloads the ripgrep binary and uses that. The Rust magicians somehow managed to implement globbing + gitignoring in a blazing fast way so we utilized their work.

I think fd is more appropriate tool for the job and I just found that there's an npm package for it: https://www.npmjs.com/package/fd-find, so maybe that's some option.

(I realize that plain Node.js implementation would be better but Rust binaries are cross-platform and usually unbelievably fast.)

borekb

comment created time in 2 months

issue commentmicrosoft/vscode

Settings Sync : Allow for custom backend service end points

Now that Settings Sync is becoming available in VSCode stable, see 1.48 update, I had to drop my previous sync data to start using the new Insiders service, i.e., a small data loss 😕 (see #104584).

I don't mind losing Insiders settings history too much but still, it made some problems of the current setup more apparent to me:

  • I don't like it that my sync history is not owned by me. It is somewhere on Microsoft's servers, in some proprietary format.
  • The format is also important – the settings sync extension used Gists which meant that not only I owned my data but also they were in a format that other "clients" could work with, for example, I could use GitHub's user interface to browse the history of my settings or git CLI to e.g. merge between Insiders and Stable.
  • The VSCode team decides which "services" are available, for example, what if I wanted to have a third service for GitHub Codespaces?

I understand that custom backends are on VSCode's team mind, just not prioritized yet. My point is only to add some more arguments for support of custom backends.

jmarandet

comment created time in 2 months

issue commentmicrosoft/vscode

How to transition to "Settings Sync Insiders service"?

@Tyriar Thanks for the comments. I miss the simplicity of Gists + this extension though – I simply had two gists, one for Insiders, one for Stable, it was such a simple mental model, I could point any VSCode instance to any of the two (or more) gists. Simple, elegant.

Now, I'm basically in a "data loss" situation if I want to transition to two separate Sync services. It's not such a big deal, plus I know it's in Insiders and therefore experimental, but if you can come up with a way to store my data to my storage (Gist, GitHub repo, Dropbox, whatever), that would be great. (That is tracked in https://github.com/microsoft/vscode/issues/92357.)

borekb

comment created time in 2 months

issue openedmicrosoft/vscode

How to transition to "Settings Sync Insiders service"?

I tried the Settings Sync: Select Service... command but it created a new profile for me, i.e., it didn't transfer the history of my settings.

What I want to achieve:

  1. In Insiders, move my synced settings to that "Insiders service".
  2. Somehow clear the original "Stable" storage.
  3. Turn on Settings Sync in Stable.

Do I understand correctly that for both services (Insiders and Stable), I can use the same GitHub account, right?

created time in 2 months

issue commentDavidAnson/markdownlint-cli2

Unintuitive handling of .markdownlintignore files

Yes, for example, if it was an ignoreGlobs key in .markdownlint.json, that would make it cleaner.

But even better would be to support the ignore format, ideally with hierarchy as well (https://github.com/DavidAnson/markdownlint-cli2/issues/2). I don't know how ripgrep or fd do that but for example, fd can find *.md files instantly between the 180k files I have in the current repo (most of that gitignored node_modules):

$ time fd -g '**/*.md' .
fd -g '**/*.md' .  0.02s user 0.02s system 270% cpu 0.014 total
borekb

comment created time in 2 months

issue commentDavidAnson/markdownlint-cli2

Unintuitive handling of .markdownlintignore files

And my "✅" updated example is even wrong – the second pattern should be **/ignored-folder/** (I learned this painfully when lint-staged was reporting markdownlint errors for MD files in the ignored folder; it uses an absolute path so my original glob didn't match it).

borekb

comment created time in 2 months

issue commentigorshubovych/markdownlint-cli

Possible to use different configs for different folders?

@DavidAnson cli2 works beautifully for this! Does VSCode extension already do this as well?

borekb

comment created time in 2 months

issue openedDavidAnson/markdownlint-cli2

What does `markdownlint-cli2 .` do?

Just curious – my muscle memory executed this command:

markdownlint-cli2 .

and it got stuck – I had to kill it with ctrl-c. I'm not sure what "." means as a glob, does it start scanning every file in the current directly, including non-Markdown ones?

created time in 2 months

issue commentigorshubovych/markdownlint-cli

Suboptimal performance when a large folder is listed in .markdownlintignore

@DavidAnson I can confirm that cli2 doesn't have this problem 🎉.

kachkaev

comment created time in 2 months

issue openedDavidAnson/markdownlint-cli2

Support hierarchical `.markdownlintignore` files

This cli2 supports hierarchical config files (.markdownlint.json) but not ignore files (.markdownlintignore). This feels inconsistent, for example, I can customize lint rules per subfolder but can't customize ignore rules in the same way.

Why this is a problem in larger repos is described here: https://github.com/igorshubovych/markdownlint-cli/issues/45#issuecomment-667671464.

created time in 2 months

issue openedDavidAnson/markdownlint-cli2

Unintuitive handling of .markdownlintignore files

It took me a while to realize that .markdownlintignore is not treated as an ignore file but rather in a custom way.

For example, this doesn't work ❌:

node_modules
/ignored-folder

This works ✅:

**/node_modules/**
ignored-folder/**

It took me a while to figure it out and I still don't like it 😄. If you could find a way to support the standard "ignore" format, that would be great.

created time in 2 months

issue commentdotansimha/graphql-code-generator

[typescript-resolvers] Generated resolver return types don't allow for async/partial resolution

Thanks! So the parent type (CustomParentType) is shared between all query resolvers? Mappers customize specific types, e.g., UserMyCustomUserType, which seems more powerful.

To ask specifically, if I have these two mappers:

mappers:
  User: ./my-models#MyCustomUserType
  Category: ./my-models#MyCustomCategoryType

is it possible to get rid of this config and replace it with generics?

dobesv

comment created time in 2 months

issue commentdotansimha/graphql-code-generator

'Add' plugin adds an empty line

It's v2, according to my yarn.lock.

borekb

comment created time in 2 months

issue commentdotansimha/graphql-code-generator

[typescript-resolvers] Generated resolver return types don't allow for async/partial resolution

We understand that resolvers are more dynamic and it's return values may be different from the type declared in the schema, so we allow you to customize it in 2 way: either with generics, or with mappers.

@dotansimha Do you have an example how to it with generics please? I also read your blog post on this but only mappers are used there.

dobesv

comment created time in 2 months

issue commentmicrosoft/vscode

Settings merge: UX feedback

Bad luck, Codespaces currently cannot turn sync on due to this error:

Settings sync cannot be turned on because the current version (1.48.0-insider, 5696babbc1dce41788bae04b1a04ad35140bebfb) is not compatible with the sync service. Please update before turning on sync.

I'll try to do it again next week or so.

borekb

comment created time in 2 months

issue commentfacebook/docusaurus

RFC: CommonMark compatibility, supporting multiple markdown parsers

An alternative approach would be to convert MD to MDX first and then just let the mdx-loader to its thing. But there probably isn't currently a convertor from MD to MDX in the unified ecosystem, though many pieces are in place: https://github.com/unifiedjs/ideas/issues/9.

slorber

comment created time in 2 months

issue commentfacebook/docusaurus

RFC: CommonMark compatibility, supporting multiple markdown parsers

plugin-content-docs that supports CommonMark for .md files

We've experimented with plain Markdown support in an internal prototype and wanted to post the key results here.

Summary

It's doable and not that complex – about 200 LoC. There's currently some ugliness like to get the ToC, we're converting AST to React components and then parsing it back to a string for which we didn't find a better solution yet but I'm sure there should be, e.g. something like hast-util-to-jsx if it was maintained.

How it's done

The rewritten plugin-content-docs-2/index.ts customizes loaders:

  • For .mdx files, use @docusaurus/mdx-loader
  • For .md files, use a custom loader (see below).

In our prototype, we first duplicate ~20 LoC from the base implementation and then customize the loaders. The entire file (certainly with opportunities for further cleanup) looks like this:

import path from 'path';

import admonitions from 'remark-admonitions';
import {STATIC_DIR_NAME} from '@docusaurus/core/lib/constants';
import {
  docuHash,
  aliasedSitePath,
} from '@docusaurus/utils';
import {
  LoadContext,
  Plugin,
  OptionValidationContext,
  ValidationResult,
} from '@docusaurus/types';

import loadEnv from '@docusaurus/plugin-content-docs/lib/env';

import {
  PluginOptions,
  LoadedContent,
  SourceToPermalink,
} from '@docusaurus/plugin-content-docs/lib/types';
import {Configuration} from 'webpack';
import {VERSIONS_JSON_FILE} from '@docusaurus/plugin-content-docs/lib/constants';
import {PluginOptionSchema} from '@docusaurus/plugin-content-docs/lib/pluginOptionSchema';
import {ValidationError} from '@hapi/joi';

import * as originalPluginContentDocs from '@docusaurus/plugin-content-docs';

export default function pluginContentDocs(
  context: LoadContext,
  options: PluginOptions,
): Plugin<LoadedContent | null, typeof PluginOptionSchema> {

  if (options.admonitions) {
    options.remarkPlugins = options.remarkPlugins.concat([
      [admonitions, options.admonitions],
    ]);
  }

  const {siteDir, generatedFilesDir} = context;
  const docsDir = path.resolve(siteDir, options.path);
  const sourceToPermalink: SourceToPermalink = {};

  const dataDir = path.join(
    generatedFilesDir,
    'docusaurus-plugin-content-docs',
    // options.id ?? 'default', // TODO support multi-instance
  );

  // Versioning.
  const env = loadEnv(siteDir, {disableVersioning: options.disableVersioning});
  const {versioning} = env;
  const {
    docsDir: versionedDir,
  } = versioning;

  const result = originalPluginContentDocs.default(context, options);
  result.configureWebpack = function (_config, isServer, utils) {
    const {getBabelLoader, getCacheLoader} = utils;
    const {rehypePlugins, remarkPlugins} = options;
    // Suppress warnings about non-existing of versions file.
    const stats = {
      warningsFilter: [VERSIONS_JSON_FILE],
    };

    return {
      stats,
      devServer: {
        stats,
      },
      resolve: {
        alias: {
          '~docs': dataDir,
        },
      },
      module: {
        rules: [
          {
            test: /(\.mdx)$/,
            include: [docsDir, versionedDir].filter(Boolean),
            use: [
              getCacheLoader(isServer),
              getBabelLoader(isServer),
              {
                loader: require.resolve('@docusaurus/mdx-loader'),
                options: {
                  remarkPlugins,
                  rehypePlugins,
                  staticDir: path.join(siteDir, STATIC_DIR_NAME),
                  metadataPath: (mdxPath: string) => {
                    // Note that metadataPath must be the same/in-sync as
                    // the path from createData for each MDX.
                    const aliasedSource = aliasedSitePath(mdxPath, siteDir);
                    return path.join(
                      dataDir,
                      `${docuHash(aliasedSource)}.json`,
                    );
                  },
                },
              },
              {
                loader: path.resolve(__dirname, './markdown/index.js'),
                options: {
                  siteDir,
                  docsDir,
                  sourceToPermalink,
                  versionedDir,
                },
              },
            ].filter(Boolean),
          },
          {
            test: /(\.md)$/,
            include: [docsDir, versionedDir].filter(Boolean),
            use: [
              getCacheLoader(isServer),
              getBabelLoader(isServer),
              {
                loader: path.resolve(__dirname, './custom-md-loader/index.js'),
                options: {
                  remarkPlugins,
                  rehypePlugins,
                  staticDir: path.join(siteDir, STATIC_DIR_NAME),
                  metadataPath: (mdxPath: string) => {
                    // Note that metadataPath must be the same/in-sync as
                    // the path from createData for each MDX.
                    const aliasedSource = aliasedSitePath(mdxPath, siteDir);
                    return path.join(
                      dataDir,
                      `${docuHash(aliasedSource)}.json`,
                    );
                  },
                },
              },
              {
                loader: path.resolve(__dirname, './markdown/index.js'),
                options: {
                  siteDir,
                  docsDir,
                  sourceToPermalink,
                  versionedDir,
                },
              },
            ].filter(Boolean),
          },
        ],
      },
    } as Configuration;
  }

  return result;
}

export function validateOptions({
  validate,
  options,
}: OptionValidationContext<PluginOptions, ValidationError>): ValidationResult<
  PluginOptions,
  ValidationError
> {
  return originalPluginContentDocs.validateOptions({validate, options});
}

The there's a custom loader – plugin-content-docs-2/src/custom-md-loader/index.ts. It looks like this in full:

import {loader} from 'webpack';
import {getOptions} from 'loader-utils';
import {readFileSync} from 'fs-extra';
import matter from 'gray-matter';
import stringifyObject from 'stringify-object';
import unified from 'unified';
import parse from 'remark-parse';
import remark2rehype from 'remark-rehype';
import rehype2react from 'rehype-react';
import React from 'react';
import rightToc from '@docusaurus/mdx-loader/src/remark/rightToc';
import slug from 'remark-slug';
import raw from 'rehype-raw';
import emoji from 'remark-emoji';
import admonitions from 'remark-admonitions';
import headings from 'rehype-autolink-headings';
import highlight from '@mapbox/rehype-prism';
import reactElementToJSXString from 'react-element-to-jsx-string';

const mdLoader: loader.Loader = function (fileString) {
  const callback = this.async();

  const {data, content} = matter(fileString);

  const options = getOptions(this) || {};

  let exportStr = `export const frontMatter = ${stringifyObject(data)};`;
  // Read metadata for this MDX and export it.
  if (options.metadataPath && typeof options.metadataPath === 'function') {
    const metadataPath = options.metadataPath(this.resourcePath);
    if (metadataPath) {
      // Add as dependency of this loader result so that we can
      // recompile if metadata is changed.
      this.addDependency(metadataPath);
      const metadata = readFileSync(metadataPath, 'utf8');
      exportStr += `\nexport const metadata = ${metadata};`;
    }
  }

  const processedMd = unified()
    .use(parse, {commonmark: true})
    .use(slug)
    .use(emoji)
    .use(admonitions)
    .use(rightToc)
    .use(remark2rehype, {allowDangerousHtml: true})
    .use(raw)
    .use(headings)
    .use(highlight)
    .use(rehype2react, {createElement: React.createElement, Fragment: React.Fragment})
    .processSync(content);

  const jsxString = reactElementToJSXString((processedMd as any).result);

  // I don't like this at all, but it's a prototype...
  // We need to get 'rightToc' data from the JSX string, so following lines
  // are about getting the info and then replacing it, along with escaping unwanted chars.
  const rightTocString = jsxString
    .match(/(export const rightToc = \[[\s\S.]*\];)/)![1]
    .replace(/(\\n)|(\\t)|(\\)/g, '');

  const escapedJsxString = jsxString
    .replace(/{\`[\S\s.]*?export const rightToc = \[[\s\S.]*\];[\S\s.]*?\`}/, '')
    .replace(/{'[\s\S]*?'}/g, `{' '}`)
    .replace(/`/g, '\`');

  const code = `
  import React from 'react';

  ${rightTocString}
  ${exportStr}

  export default function MDLoader() {
    return (${escapedJsxString});
  }
  `;

  return callback && callback(null, code);
};

export default mdLoader;

If there wasn't the ugly React to string parsing code, it would actually be quite simple.

The downside from the maintenance point of view is that the MD loader is explicit about its unified.js plugins while the MDX loader is a bit more indirect / obscure, so there would be two places to maintain this configuration. But I think this could be refactored to be more aligned, and even in the worst case, it's like 15 lines of code and the default set of plugins probably isn't changing that often.

Overall, it seems feasible to me.

slorber

comment created time in 2 months

issue commentigorshubovych/markdownlint-cli

Suboptimal performance when a large folder is listed in .markdownlintignore

Thanks, I'll try to experiment with it sometimes soon.

kachkaev

comment created time in 2 months

issue commentigorshubovych/markdownlint-cli

Suboptimal performance when a large folder is listed in .markdownlintignore

I've got a .markdownlintignore file with this contents:

node_modules
/prototypes

I've got 35 *.md files and running plain markdown link in the folder takes about half a minute.

I tried constructing the command differently, not depending on .markdownlintignore, and am betting sub-second time:

npx markdownlint -i prototypes $(fd -g "*.md" -E "prototypes" . | tr '\n' ' ')

Is this the same issue reported here?

kachkaev

comment created time in 2 months

issue commentmicrosoft/vscode

Settings merge: UX feedback

Thanks, @sandy081, I'll be glad to do that. How do I reset reset the Codespaces' settings.json to the state before the merge? That version doesn't appear in the Settings Sync view if I'm not missing anything (I can only see remote versions).

BTW I'm attaching my "main" (remote) settings file: settings.json

borekb

comment created time in 2 months

issue openeddotansimha/graphql-code-generator

'Add' plugin adds an empty line

I'm constructing a schema.graphql file with the AST plugin and also want to add a comment to the top. This is from my codegen.yml:

generates:
  schema.graphql:
    schema:
      - schema-source.ts
    plugins:
      - schema-ast
      - add:
          content: '# Generated - DO NOT EDIT'

Besides prepending the content, it also appends an empty line which feels like a bug to me:

Screenshot 2020-08-06 at 10 17 13

created time in 2 months

issue commentexcalidraw/excalidraw

Feature Request: Color Picker

For reference, Balsamiq also don't have a color picker but I find their color palette much more suitable for my real-world needs, probably because there are several hues for each color.

Screenshot 2020-08-05 at 09 53 48

But people still requests custom palettes / remembering previous choices / color picker in Balsamiq products 😄.

My point of view:

  • Remembering previous custom values would indeed be useful.
  • Maybe full color picker could be behind something like option-click or something (agree that the simplicity of the the primary UI is important).
AleksandrHovhannisyan

comment created time in 2 months

issue openedmicrosoft/vscode

Settings merge: UX feedback

I was invited to GitHub Codespaces where I turned on the settings sync. It reported some conflicts so I opened this diff mode:

Screenshot 2020-08-04 at 14 36 26

A few things that I found confusing about the UX:

  1. Since this is the first other machine I'm adding to sync (so far, I've only had this enabled in VSCode Insiders on my Mac), why am I seeing a conflict?

  2. Some of the diffs are plain reformatting (e.g., blank lines removed), why was it done?

  3. The reformatting also stripped some of my comments (this is a data loss, technically speaking):

    Screenshot 2020-08-04 at 14 51 03

  4. Some lines seem to be moved from the top of the file:

    Screenshot 2020-08-04 at 14 43 12

    to the bottom:

    Screenshot 2020-08-04 at 14 44 00

    It only happened for a couple of lines, I'm not sure why.

  5. I'm not sure what "Accept Merges" means. Will that eventually sync back to my Mac machine and will I e.g. lose the comments?

    UPDATE: there's a confirmation after that. Maybe the button should say "Accept Merges..." (note the ellipsis.)

    Screenshot 2020-08-04 at 15 04 39

created time in 2 months

pull request commentlfades/next-with-apollo

WIP feat: apollo-client@2 → @apollo/client@3

@ilackovic Actually we've moved utils/apolloClient to _app.tsx since it's so short, the entire file now looks like this:

import React from 'react';
import { ApolloProvider, ApolloClient, HttpLink, InMemoryCache } from '@apollo/client';
import NextApp, { AppProps } from 'next/app';
import withApollo, { InitApolloOptions } from '@sotnikov/next-with-apollo';
import { getDataFromTree } from '@apollo/client/react/ssr';

type Props = AppProps & {
  apollo: ApolloClient<{}>;
};

const App = ({ Component, pageProps, apollo }: Props) => (
  <ApolloProvider client={apollo}>
    <Component {...pageProps} />
  </ApolloProvider>
);

App.getInitialProps = async (appContext: any) => {
  const appProps = await NextApp.getInitialProps(appContext);
  return { ...appProps };
};

export default withApollo(
  ({ initialState }: InitApolloOptions<any>): ApolloClient<any> => {
    return new ApolloClient({
      link: new HttpLink({
        uri: 'http://localhost:3000/api/graphql',
      }),
      cache: new InMemoryCache().restore(initialState || {}),
    });
  },
  { getDataFromTree }
)(App);

sotnikov-link

comment created time in 2 months

delete branch borekb/graphql-tools

delete branch : update-mergetypedefs-docs

delete time in 2 months

issue commentigorshubovych/markdownlint-cli

Possible to use different configs for different folders?

Looks very good, thanks! I won't be able to test this soon but will keep that in mind for future updates of our dev infra.

borekb

comment created time in 2 months

issue commentigorshubovych/markdownlint-cli

Make ignores and files to include part of the configuration

Thanks for the info. Note that a single, root-level ignore file can be a maintenance pain point in larger repos, see e.g. these feature requests for Prettier and ESLint:

  • https://github.com/prettier/prettier/issues/4081
  • https://github.com/eslint/eslint/issues/13389

But any improvements in this area are welcome (though I won't be able to test the new behavior soon, sorry).

borekb

comment created time in 2 months

issue commentardatan/graphql-tools

mergeTypeDefs doesn't require `all: true` for the same type twice (?)

Thanks for the info, I've submitted a small PR https://github.com/ardatan/graphql-tools/pull/1869 updating this.

borekb

comment created time in 2 months

PR opened ardatan/graphql-tools

Update mergeTypeDefs docs

Fixes #1864.

Remove the obsolete {all: true} example.

+4 -7

0 comment

1 changed file

pr created time in 2 months

PR closed borekb/graphql-tools

Update mergeTypeDefs docs

Fixes #1864.

Remove the obsolete {all: true} example.

+4 -7

0 comment

1 changed file

borekb

pr closed time in 2 months

PR opened borekb/graphql-tools

Update mergeTypeDefs docs

Fixes #1864.

Remove the obsolete {all: true} example.

+4 -7

0 comment

1 changed file

pr created time in 2 months

create barnchborekb/graphql-tools

branch : update-mergetypedefs-docs

created branch time in 2 months

fork borekb/graphql-tools

:wrench: Build, mock, and stitch a GraphQL schema using the schema language

https://www.graphql-tools.com

fork in 2 months

more