Fix logic bug in create_schedule() re. backfills

Don't ask for immediate trigger when a backfill is requested, and don't ask for a backfill when an immediate trigger is requested.
Closes #678.

In general I like us to always create a failing test when fixing a bug. Have you looked into how difficult that would be to do here?

I am unsure if this is worth adding tests for, but I can. I'd tried to tweak test_schedule_backfill() but that didn't work in the way I expect, so I'd have to spend some time actually learning how schedules work and writing a new test, I think.

In general I like us to always create a failing test when fixing a bug. Have you looked into how difficult that would be to do here?

lol, we crossed on the wire. Yes, I think it would take me a couple (more) hours since I'm not really familiar with schedules. (That's not counting the hour or two I've already spent trying to tweak an existing test to validate this as well.)

Does any SDK have tests for this functionality? If so, we could appeal to an argument for coverage by analogy to the other SDK. (Also it might teach us how to provide coverage here.)

Does any SDK have tests for this functionality? If so, we could appeal to an argument for coverage by analogy to the other SDK. (Also it might teach us how to provide coverage here.)

I don't believe this is relevant in any other SDK; TypeScript exposes schedule creation in a different way. Go is kinda similar but does not test this so far as I can see. Java also has a completely different approach using builders.

hm, looking at some of the CI failures (which I did not see running locally that I can recall), I'm wondering if the existing tests actually ARE sufficient but were just wrong. I was hoping this would be straightforward but I think I'll need to dig more anyway.

schedule_backfills is yes, that's how we know we've fixed this bug. :) The search-attribute update one appears to be an unrelated intermittent failure.

schedule_backfills is yes, that's how we know we've fixed this bug. :)

Right (that's what I meant by desired failures). When reviewing I usually run the tests from the PR with the feature changes reverted to ensure that there is a test failure on main as there should be.

The search-attribute update one appears to be an unrelated intermittent failure.

OK great, I must have been having bad luck with that one.


Example in the README does not seem to work on a local X server

python3 -m dockerx.run --image nvidia/cuda:11.0-base --nvidia 1 --command '/bin/bash -c "apt update && apt install -y x11-apps && xclock"'

It does work, just need to wait a bit.


Bug: table view

Bug: table view https://ecency.com/hive-125125/@zakludick/mobey-ludick-household-hive-progress-9e9dfdb7ce598

Current table behaviour is default by render-html, first I am trying a plugin, if that does not work will think of something else...
Trying this...
https://www.npmjs.com/package/@native-html/table-plugin

@feruzm this is something we can further work on... that being said... we will lose some of customisation with did with rendering images inside table cells.
https://user-images.githubusercontent.com/6298342/158122303-d89b03e4-e217-4b56-a9f7-e8a4054bd88c.mov

hmmm... it will open more issues then solving i guess....
Plugin implementation
https://user-images.githubusercontent.com/6298342/158123621-65c6965c-fd31-490d-bbdd-a27c496c6b39.mov
Current implementation


marathon creates lots of zero byte /tmp/MIMEXXXX.tmp files

I suspect this is just the manifestation of https://java.net/jira/browse/JERSEY-2515.

Marathon reproducibly drops one of these files every time it is restarted.

Note: This issue has been migrated to https://jira.mesosphere.com/browse/MARATHON-3338. For more information see https://groups.google.com/forum/#!topic/marathon-framework/khtvf-ifnp8.


ARM: handle checking aliases with out-of-bounds GEPs

A global alias may use indices which are not considered in bounds.  In
such a case, accessing the base object will fail as it only peers
through inbounds accesses.  This pattern is used by the swift compiler
to create references to preceeding members in the type metadata.  This
would cause the code generation to fail when targeting a platform that
used ELF as the object file format.  Be conservative and fail the
read-only check if we run into an alias that we cannot peer through.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@345107 91177308-0d34-0410-b5e6-96231b3b80d8

CC: @DougGregor @bob-wilson @jrose-apple

This is a cherry-pick of SVN r345107 from upstream that addresses the current build failure when building armv7 targets

I don't know why Swift would have to use non-inbounds GEPs to access members at negative offsets in type metadata, but this change certainly seems necessary.

@rjmccall I introduced one of the non-inbounds geps: the requirements base descriptor is an alias that points one step before the first requirement in a protocol descriptor; see https://github.com/apple/swift/blob/master/lib/IRGen/GenMeta.cpp#L688-L695

@DougGregor My understanding is that the alias doesn't change the notion of what's "the same object" for the purposes of inbounds.  Presumably the alias still points within the overall protocol descriptor?

@rjmccall it still points within the overall protocol descriptor, but the specific type is a bit of a lie.


Install with homebrew?

I usually install this sort of thing on OSX with homebrew.  It took me a while to figure out this is possible with
$ brew install --HEAD homebrew/head-only/git-hooks

Would you take a PR to add this to the README?

+1

:+1:

@icefox ping

:+1:

git-hooks has been in homebrew/core for a while now, so closing this issue.


Unable to start on marathon 1.5.2

I'm running Marathon 1.5.2 with Mesos 1.4.1
Trying to bring up marathon-slack 0.4.0 and its constantly failing to deply here are my stdout/stderr logs
--- stderr ---
I1208 18:02:29.702464  9335 exec.cpp:162] Version: 1.4.1
I1208 18:02:29.704879  9362 exec.cpp:237] Executor registered on agent f9eb53b4-b3dd-4731-a44c-7f1e39139d67-S2
I1208 18:02:29.705446  9349 executor.cpp:120] Registered docker executor on prod-mesos-slave-01.aws.octanelending.com
I1208 18:02:29.705591  9354 executor.cpp:160] Starting task marathon-slack.f4123b7e-dc41-11e7-9487-02707643caf4
I1208 18:03:46.645203  9362 executor.cpp:269] Received killTask for task marathon-slack.f4123b7e-dc41-11e7-9487-02707643caf4
I1208 18:03:47.891160  9364 process.cpp:1068] Failed to accept socket: future discarded
--- stdout ---

<EMAIL_ADDRESS>start /usr/local/marathon-slack
node index.js

Event { type: 'error' }
Express server listening on port 31314 on <IP_ADDRESS>
Event { type: 'error' }
Event { type: 'error' }
Event { type: 'error' }
Event { type: 'error' }
Event { type: 'error' }
Event { type: 'error' }
Event { type: 'error' }
{
  "id": "/marathon-slack",
  "cpus": 0.1,
  "mem": 128,
  "disk": 0,
  "instances": 1,
  "user": "octane",
  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "tobilg/marathon-slack:0.4.0",
      "network": "HOST",
      "privileged": false,
      "forcePullImage": true
    }
  },
  "env": {
    "MARATHON_HOST": "marathon.mesos.prod",
    "MARATHON_URL": "marathon.mesos.prod",
    "SLACK_WEBHOOK_URL": "https://hooks.slack.com/services/xxx",
    "SLACK_CHANNEL": "#tech-infrastructure",
    "EVENT_TYPES": "deployment_info,deployment_success,deployment_failed,failed_health_check_event,health_status_changed_event,unhealt>
  },
  "labels":{
    "MARATHON_SINGLE_INSTANCE_APP": "true"
  },
  "upgradeStrategy":{
    "minimumHealthCapacity": 0,
    "maximumOverCapacity": 0
  },
  "portDefinitions": [
    {
      "port": 0,
      "protocol": "tcp",
      "name": "api"
    }
  ],
  "requirePorts": false,
  "healthChecks": [
    {
      "protocol": "HTTP",
      "portIndex": 0,
      "path": "/health",
      "gracePeriodSeconds": 5,
      "intervalSeconds": 20,
      "maxConsecutiveFailures": 3
    }
  ]
}

I think the MARATHON_URL can be removed. Have you checked if the agent which runs the task can resolve the marathon.mesos.prod domain? Is Marathon running on Port 8080?

@tobilg yes as stated everything works if I downgrade to marathon-slack-1.2.0
I have no problem launching the following
{
  "id": "/utility/marathon-slack",
  "cpus": 0.1,
  "mem": 256,
  "disk": 0,
  "instances": 1,
  "user": "octane",
  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "tobilg/marathon-slack:0.1.2",
      "network": "HOST",
      "privileged": false,
      "parameters": [],
      "forcePullImage": true
    }
  },
  "env": {
    "MARATHON_URL": "marathon.prod.mesos",
    "SLACK_WEBHOOK_URL": "https://hooks.slack.com/services/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",
    "EVENT_TYPES": "deployment_info,deployment_success,deployment_failed,failed_health_check_event,health_status_changed_event,unhealthy_task_kill_event"
  },
  "labels":{
   "MARATHON_SINGLE_INSTANCE_APP": "false"
  },
  "upgradeStrategy": {
    "minimumHealthCapacity": 0.5,
    "maximumOverCapacity": 0.1
  }
}


Bug: Executable is back with huge size

Operating system: Windows, Mac OS, Linux
qt-ts-tools version: 0.6.0
Problem's description:
The executable went from a 1.7MB to 3.4MB size. This feels inappropriate.
Expected behavior / output:
The executable should have a more reasonable size.
Note

Investigate Itertools::merge replacement.
Investigate i18n-embed minimalization.
Investigate dropping less used terminals.

https://crates.io/crates/cargo-bloat/0.6.1
https://github.com/johnthagen/min-sized-rust

Pretty nice resources

The culprit was both DesktopLanguageRequester from i18n-embed and env_logger. They pulled in regex which adds significant overhead for such a simple application.


Empty state for  class view

If the user click outside of a method and in a class we show 'no insights'.
We should either:

If we can find endpoints or spans in the class, show the 'No data' empty state
Otherwise show the No Insights empty state

@doppleware soon with the new UI, our focused object cannot be class (outside of method),

Do we still want to address this issue at all now?
Should we consider in the new UI to have focus on entire file (or class, or multiple classes)?

Yes we'll have an option to see all assets in a specific class, so this empty state will still be important

blocked by #280 since we have client side discovery and we must have the scope of insights per method (and from that insights by class), only then we could know if there are no really insights per class


MSID: 88088 Version: 2 DOI: 2<IP_ADDRESS>3773

[PLACE MANUSCRIPT AND EDITOR DETAILS HERE WHEN AVAILABLE] See step 3
[PLACE PDF URL HERE WHEN AVAILABLE] See step 7
Step 1. Inform bioRxiv
Who can help: @QueenKraken, @nlisgo, @scottaubrey

[x] Manuscript is in data hub index (https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=88088)

Step 2. Create preview of manuscript
Who can help: @fred-atherden, @nlisgo, @scottaubrey

[ ] Manuscript is available for preview (https://prod--epp.elifesciences.org/preview/88088/v2)

[ ] Trigger import for staging: https://prod--epp.elifesciences.org/import
[ ] Sync data folder with s3://prod-elife-epp-data/data
[ ] Trigger import for staging: https://staging--epp.elifesciences.org/import
[ ] Sync data folder with s3://staging-elife-epp-data/data
[ ] Pull request created to enhanced-preprint-data
[ ] Post link to pull request below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-manuscript
Step 3: Awaiting public reviews and QC
Who can help: Production team

[ ] QC passed or QC not needed

Who can help: Editorial team

[x] Public reviews available on sciety (https://sciety.org/articles/activity/10.1101/2<IP_ADDRESS>3773)
[ ] Manuscript and editor details at the top of this issue (Supplied by Editorial team)
[x] Reviews returned by EPP - https://prod--epp.elifesciences.org/api/reviewed-preprints/88088/v2/reviews

Example
"msas": "Genetics and Genomics", "Neuroscience"
"msid": "84628"
"version": "1"
"preprintDoi": "10.1101/2<IP_ADDRESS>4241"
"articleType": "Reviewed Preprint"
"status": "Published from the original preprint after peer review and assessment by eLife."

"Reviewed Preprint posted": "2023-01-02"
"Sent for peer review": "2022-10-28"
"Posted to bioRxiv": "2022-11-21" (link: "Go to bioRxiv": "https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>4241v1")

Editors:
Reviewing Editor
Michael B Eisen
University of California, Berkeley, United States
Senior Editor
Michael B Eisen
University of California, Berkeley, United States

Step 4: Modify manuscripts.json (no PDF)

[ ] Reviewed preprint is published to EPP (https://elifesciences.org/reviewed-preprints/88088)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[ ] Request that a doi be registered

[ ] Post link to #enhanced-preprint comment below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]

Instructions to modify manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/publish-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/334/files
Once the pull request is merged in it should be available a few minutes later.

Request that a doi
Post the following in #enhanced-preprint:
@Fred can you register a doi for https://elifesciences.org/reviewed-preprints/88088

Step 5: Awaiting search reindex

[ ] Reviewed preprint is avaliable on journal homepage (https://elifesciences.org)

The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.

Additional info
If needed, the jenkins pipeline to reindex search can be triggered sooner.
https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 6: Published! Request PDF generation

[ ] Post the link to the PDF url at the top of the issue

[ ] Post link to #enhanced-preprint comment below

#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]
Post the following to the #enhanced-preprint on slack:
@Ryan Dix-Peek please can you generate a PDF for https://elifesciences.org/reviewed-preprints/88088

Step 7: Introduce PDF to data folder and git repo

[ ] PDF is avaliable at https://github.com/elifesciences/enhanced-preprints-data/raw/master/data/88088/v2/88088-v2.pdf

Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-pdf
Step 8: Add PDF url to manuscripts.json

[ ] Reviewed preprint PDF is available for download (https://prod--epp.elifesciences.org/reviewed-preprints/88088)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[PLACE LINK TO PULL REQUEST HERE]

Instructions to add PDF url to manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/add-pdf-url-to-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/397/files
Once the pull request is merged in it should be available a few minutes later.

Step 9: Done!

[ ] Kettle is on!

@naushinthomson v3 is now loaded. Please could you check this one again?


Change flaky tests into unit tests

For #4468

[x] Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR)
[x] Title summarizes what is changing
[x] Has a news entry file (remember to thank yourself!)
[n/a] Has sufficient logging.
[n/a] Has telemetry for enhancements.
[x] Unit tests & system/integration tests are added/updated
[n/a] Test plan is updated as appropriate
[n/a] package-lock.json has been regenerated by running npm install (if dependencies have changed)
[n/a] The wiki is updated with any design decisions/details.

Refreshing the build to see if the new connections are working ;)


Roadmap

General roadmap for upcoming ReactQL features, and a tentative order they'll be approached.
Feel free to suggest any features you'd like to see in this thread, and they'll be considered for inclusion.
Note: The raison d'être of ReactQL is to remain a lightweight, general purpose starter kit for building GraphQL-backed front-ends. Niche features should generally be built on top of the kit, rather than wind up in core. But all sensible use-cases and suggestions will be considered.
Soon:

[x] ReactQL CLI, installed via npm i -g. Easily spawn a new project with reactql new instead of manual git clones and tidy-up. Will make it easier to version the kit and distribute the start-up code offline.

[x] Yarn building. Should speed up equivalent npm installs of modules.

[x] Better SASS/LESS imports. The loader config needs tweaking to standardise import styles between different CSS loaders. Could also do with a better strategy for importing third-party classes globally or locally, for better framework support -- Semantic, Bootstrap 4, etc.

[x] Typescript option.

[x] Development web server, that restarts automatically on code changes, alongside the existing hot-code reload Webpack dev server.

[x] Deterministic versioning- have one kit version per CLI installation, which can alert when there's an update available, so there are no surprises when creating a new project and finding that the kit has changed.

[ ] Helper component for code splitting and loading screens a la #3, along with updated docs.

[ ] Video guides & articles in docs for common use cases and code tutorials on how to use GraphQL in practice like how to build a GraphQL server on top of the kit, etc.

[x] ~i18n / l10n internationalisation / localisation support~ (After some testing, it's clear that i18n is far too opinionated to suit every use case-- libs, translation loading strategies, etc will differ widely per project. I'll save this one for a future 'examples' kit)

[ ] Comparison with Next.js, et al, so it's more obvious when GraphQL is a win, and where other choices might serve users better.

Future / tentative

[ ] Progressive web app features (#40)

[ ] Mobile/desktop framework support, for creating Cordova/Phonegap/Electron apps.

Example kits

[x] Running a local GraphQL server on top of the existing web server, for monolithic apps that don't have a separate service (see https://github.com/reactql/examples/tree/master/graphql-server)

[x] No GraphQL. For times when you need to connect to a legacy REST endpoint instead. Feature a Redux example. (see https://github.com/reactql/examples/tree/master/no-graphql)

[ ] i18n / internationalisation. (Originally, I wanted this in core, but there are far too many ways this could be done. An example starter is probably best.)

[ ] GraphQL subscription examples and patterns. Possible web socket proxy via the built-in server? (needs more thought)

How would you feel about using react-loadable as the higher order component for code-splitting? Using it's babel plugin it works well with with webpack, server side rendering, and ensuring that the react checksum matches on client side hydration. James Kyle has a gist to show how server side rendering would work with it, but I haven't yet seen any examples of it working yet.

Thanks @jtmthf, looks promising. Will play around with it and see if it fits the build flow.

One more thing I'd like to see, but I'm not sure if it fits within the scope of ReactQL, is SVG icon support.
I know you there's already a loader for .svg files, but you can't have the SVG match the color or size of text, or do mouse-overs, or other fancy effects with <img> tags. Also, loading each SVG individually isn't as efficient as packing them into a spritesheet.
Something like svg-sprite-loader or external-sprite-loader would be good. However, the latter won't work on CDNs as far as I'm aware because of a stupid CORs issue the browser vendors refuse to fix, and the former doesn't support SVGs in CSS.
Alternatively, the icons could be packed into a webfont, which is still the better solution IMO. However, I haven't seen a loader that does this this yet.
Icons are pretty popular in web apps, so I think some sort of icon solution would be good.

@mnpenner, I'm toying with the idea of building a modular 'recipe' build flow for the starter kit, where it'd be possible to add in separate loaders out-the-box by either specifying options on the command line, or working through some kind of CLI wizard. This would make it possible to add in supported loaders like the SVG support you mentioned, but without need to anticipate every use-case and causing bloat for those that don't specifically need it.
Already, including SASS and LESS is probably an assumption too far for many dev, but included in every kit by default. I've started a 'cli' branch locally that would turn the basic git clone instructions into an interactive reactql CLI on Windows/Mac that would help spawn projects, run recipes against them, bundle, etc.
I imagine it something like Semantic UI's wizard (but without gulp):

Still working through it, but something like that is my goal.

@leebenson Hah... I started pretty much the exact same thing like a week or two ago. I'll make it public so you can take a look. It's not very far long along though. You're welcome to pillage anything you think is useful. In particular, I used prettier to clean up the source after I finish generating it, and I was planning on keeping a versions.js file which maintains versions of the packages that I know are compatible with each-other, and it also means I don't have to query npmjs.com to get the versions.
My goal was to generate a webpack config file that's still human-readable and editable at the end so that you can tweak it as much as you need. I realized that there's far too many questions that you can ask a person, so it's probably better to leave some questions out, just ask the big ones, and they can modify it later.

Just a heads-up that the first version of the CLI has now been released with the 2.0.0 tag.

Quick start
Install the ReactQL CLI on Mac/Windows/Linux:
npm i -g reactql

Then run reactql for help, or reactql new to start a new project.

This is an early first version, so if you run into any issues, please let me know and I'll get them looked at ASAP.
I've tested the kit on OS 10.12.4 and Windows 10, and it seems to working okay so far. I haven't tested on Linux yet. Any testing you could do yourselves would be greatly appreciated- and I'd be really interested in your feedback.
These are the main features:

CLI completely replaces manual git cloning. Just install and type react new whenever you want to start a new project.
Command line options can be used instead of the wizard - type react to see a full list of commands and options.
Easy future versioning. Just npm i -g reactql to get the latest kit at any time (whenever you use the CLI, it'll check NPM for the latest version and alert you if a new one is available.)
Clear separation of 'starter' and 'cli' code-- everything for the starter kit simply goes in the starter folder in this repo. Everything to do with the cli goes in cli. Simple.
No manual tidy-up -- a new starter kit has no .git/README/LICENSE to rip out. You can git init in your new folder neatly.
Auto population of package.json, based on your project name and description.
Auto installation of dependencies. It'll prefer yarn, but drop back to npm if it's not available.
Early groundwork for templating. Adding a .reactql extension to a filer inside starter/files will run it through an EJS parser with the command line args before dumping a compiled version in the new starter kit, minus the .reactql extension. This is early work against starter kit options that will be presented in the wizard, for enabling SASS, LESS, ESlint, other loaders, etc.
Usage instructions shown on the screen after installation - npm start runs it.
Emojis FTW! (only enabled on Mac)

This is still early work, so I expect there might be some issues, and code may be a little messy in places (I wrote this over the weekend.) But I think it should be a pretty good start.
Known issues:

As mentioned, no dynamic options (yet). You get exactly the same kit as v1 for now.

Windows installation via NPM is pretty terrible. I clocked 116s to build on a relatively new/fast Windows machine, on a 200mbps connection. Yarn on a Mac, by contrast, did it in 39s flat. Bear in mind this is a full installation without a 'warm' cache.

I don't include a yarn.lock file in the starter by default, because of the potential of making dynamic additions to package.json depending on user options (coming soon). It's probably best still to have a base lock file, however, to give Yarn a starting point-- I'll likely do that in the next version.

Thinking about the templating engine some more (intended to allow the user to enable/disable various loaders, drop CSS support, etc), I'm considering separate repos instead.
There could be a common 'base' repo, which is bare-bones -- no CSS, no SASS/LESS, no ESLint, etc. just the bare minimum to get it run. Then a 'kitchen sink' version, which is every best-practice and configuration option, with possibly a couple of other flavours for experimental or community driven approaches.
This would allow devs to choose from a slim starter kit, or something more comprehensive for starting a new project.
If the code is laid out in a slightly more modular way, it may be possible to inherit from a base repo and then just layer on top. I need to think about that some more, but maintaining needn't be difficult if done properly. And it'd provide a lot more flexibility than template files with conditional statements to include/exclude lines of code.
In this model, the CLI would be relegated to the simple role of letting the user choose the theme, and then downloading/extracting the appropriate .zip directly from github. The user would always be extracting the latest version, so it becomes somewhat evergreen, except for additional 'themes' being made available.
What do you think? Would you be interested in being able to choose from several 'flavours' of kit with additional features?

@leebenson Yep! That‘s a good way to go IMO. Nice job with the CLI!

@leebenson I like that approach better over templating. I used redux-cli about a year ago which uses ejs templates for code, but it was hard to work with because the templates weren't real javascript. I ended up writing a poorly maintained eslint plugin for ejs specifically for that project, but I'm not sure if it even works anymore.
Any ideas yet on how upgrading will work? Having the easy upgradeability of Next.js and create-react-app would be ideal, but being able to customize anything when needed is great too.
Related to customization, I was thinking about how Storybook currently handles this by providing both a simple config mode and a "full control" mode. For example if a developer needed to add a single loader, it would be nice if there was a configuration file separate from kit that they could add it to and have it "just work". That way developers don't have to dig through a complicated webpack config and worry about future upgrade conflicts for simple config changes.

I prefer this starter kit specifically because I can customize anything. If you were to remove that ability in favour of upgradeability, I think that might be a deal-breaker. That said, upgradeability certainly is nice, just not in lieu of flexibility. To do this right, I think it needs to be very modular. Lots of small helper scripts/functions that can be subbed out as needed. The source for those can be tucked away so that they can be upgraded without conflicts.
As for the repo-splitting: I think it's OK, as long as the CLI tool downloads and manages those automatically. I don't want to be cloning 5 different projects to get all the functionality I need. That defeats the purpose of a starter kit. If I wanted that, I'd download and install webpack, React, GraphQL and whatever else myself.
I don't think I mind too much if the CLI tool itself gets fat because of all the functionality it supports. In the end, it spits out a ready-made project, and as long as you didn't pick too many options, that project would still be "light". So, whether or the CLI tool is one repo or many doesn't matter to me as a user, however, for the purposes of maintaining the tool, multiple projects may be easier as long as you can ensure that they don't become incompatible with each-other. Babel comes to mind -- they split that into many packages and it seems to be working for them, so maybe it's doable -- but it is a pain in the butt because every time I add or remove a plugin/preset from my .babelrc I also have to npm install/uninstall it.

@leebenson I like that approach better over templating. I used redux-cli about a year ago which uses ejs templates for code, but it was hard to work with because the templates weren't real javascript.

That's the issue I ran into here. Mixing EJS (or any templating) with turns it into a weird hybrid that is tough to maintain, and will fail every linter. Makes editing/maintaining the kit less fun than I'd like.

Any ideas yet on how upgrading will work? Having the easy upgradeability of Next.js and create-react-app would be ideal, but being able to customize anything when needed is great too.

Thinking about it some more, I'm not sure upgrading is that big of a priority. With frameworks like Meteor, where the whole platform is hidden behind a CLI and the only code written is userland, there are clean lines between what is 'kit' and what is 'code'. Here, the starter kit and user code is tightly coupled, and this fusion will make it hard to do auto-upgrades without some very intelligent merge strategy to figure out what has changed. It's mirky territory to start digging into.
There are plenty of frameworks (Next.js, et al) that hide the build details from the user and upgrading simply means bumping the Next libs that are imported. My intention with this starter kit was instead of expose the whole lot so it could be configured by the user without any larger ecosystem buy-in. Upgrading kinda breaks with that.
Besides, in practice, upgrading generally won't be that hard. Just start a new project, copy over src to the latest kit, and tweak whatever kit changes were made between versions. At least it forces developers to understand what's happening under the hood and determine whether the changes make sense to them, IMO.

Related to customization, I was thinking about how Storybook currently handles this by providing both a simple config mode and a "full control" mode. For example if a developer needed to add a single loader, it would be nice if there was a configuration file separate from kit that they could add it to and have it "just work". That way developers don't have to dig through a complicated webpack config and worry about future upgrade conflicts for simple config changes.

I've used Storybook on multiple projects, and wrestled with their webpack config more than a time or two to get it to fit with the config of the underlying project I'm trying to test. I ended up writing code that attempted to 'extend' the config, and merge in changes via Object.assign. It was very messy, and if Storybook added or changed a config option, it would often through up my brittle merge expectations.
I get the benefit of offering a framework, but I think sticking to the raison d'etre of ReactQL being a starter kit is probably best.

I prefer this starter kit specifically because I can customize anything. If you were to remove that ability in favour of upgradeability, I think that might be a deal-breaker. That said, upgradeability certainly is nice, just not in lieu of flexibility. To do this right, I think it needs to be very modular. Lots of small helper scripts/functions that can be subbed out as needed. The source for those can be tucked away so that they can be upgraded without conflicts.

Agreed. Per my comment above, I'm not sure upgrading will generally be that tough. In a starter kit like ReactQL, version bumps don't need to happen just because the new kit has a higher number than the one you're using. Knowing when to fork your code and start maintaining it outside of the kit is just as important.

As for the repo-splitting: I think it's OK, as long as the CLI tool downloads and manages those automatically. I don't want to be cloning 5 different projects to get all the functionality I need. That defeats the purpose of a starter kit. If I wanted that, I'd download and install webpack, React, GraphQL and whatever else myself.

That's the whole point of the CLI - to ask a bunch of questions, handle the download/building and leave you with code you can immediately edit. You'd download the CLI one-time, and it'd handle the rest for you.

Last thought -- if I have to start using this reactql CLI tool for everything instead of npm/yarn, you're also removing some transparency. What is this tool doing? Why do I have to use it to install a package? How do I do these things without this tool?

That's definitely not my intention. IMO, the CLI should be there one-time - right at the start of the project, to get the initial code. Then, the code is yours, and you're not 'locked' into the ReactQL ecosystem, but instead building with 'native' NPM commands and everything else that the libraries you're using expose directly.
This is in contrast to, say, the Meteor CLI, which provides a ton of ongoing functionality and the entire framework that you invoke every time you run your code. That approach works great for full frameworks, but is too big a buy-in for a starter kit, IMO.

I've just released 2.2.0 which relegates the CLI to a pure build tool. The starter kit code is now located at https://github.com/reactql/kit
Future issues should be posted above as needed. The CLI issue board will specifically be for the CLI tool only.
This is a precursor to allowing multiple 'flavours' of kit to be hosted and maintained separately, each with its own contributors/maintainers and issue boards. I don't necessarily want to encourage lots of different kits, but at a minimum I see two - the 'kitchen sink' version above, and perhaps a 'slim' version that removes the CSS, optional loaders and examples found in the fuller variant.
Right now, the CLI automatically downloads, extracts and builds the full version, with no other kits to choose from. Eventually, the 'slim' option will be added too, and this will appear during invocation of reactql new where the user can select which variant of kit they wish to download.
I think this is a cleaner separation of concerns than bundling code along with each kit, and having lots of different EJS templates that include/drop lines of code depending on deeply nested if statements. It should be far easier to maintain and work with.
The other nice thing is that you can pull the repo code directly if you wish to bypass the CLI altogether. The CLI is now simply a helper.
Tested it on Mac and Windows 10 and appears to be working well.

@leebenson will the list of kits be hard-coded into CLI or will there be an option to pass in a URL to a third-party kit such as how create-react-app has its --scripts-version flag? Or perhaps both?

Hard-coded, at least for now. I don't have any plans to support third-party kits - I think that's mirky territory for ReactQL branding. Third-party kits are free to fork the CLI, though.

Okay reason why I ask is I have a TypeScript fork of the kit that some could find useful. Identical to the original except for the application code and the transpilation step of the build.

@jtmthf - if you're interested in maintaining an official Typescript version, I'd be happy to set-up a kit.ts repo and appoint you as a maintainer. Up for it?

@leebenson That'd be great! What I've been doing so far and plan to continue with, is to track kit and only make TypeScript specific modifications.

Cool, thanks @jtmthf. I've invited you to the repo @ https://github.com/reactql/kit.ts
Once that's up and running, I'll update the CLI to let devs choose between the JS or TS version.

FYI, you can now choose between Javascript (ES6) and Typescript flavours of the kit in the CLI, released in 2.3.0

Heads-up: Kit v1.3.0 was just released, which adds a development web server that restarts automatically on code changes -- making it easier to test CSS output and SSR on-the-fly, without manually re-bundling on the command line.
The next ReactQL CLI project you create will add this capability for you via the usual npm start.
There's also a ton of other improvements, including neater Webpack messages, ESLint speed improvements and a fix for Atom, colour console messages that show local network bindings and ports in dev/production, <NotFound> and <Redirect> components for isomorphic 404/301/302 handling (some extra helper boilerplate in the server entry is coming soon) and the new npm run build-static, that will generate a production browser bundle and index.html, that's ready to upload a fully working app to a static host of your choice. There's also npm run static that spawns a local server to test your static bundle, on port 5000.
See the release log for details.

CLI v2.4.0 has been released. It adds deterministic versioning of the kit; each CLI release is associated with one JS / Typescript kit pair, making it clear what you're installing and making it easy to install the same version of the kit elsewhere.

The update notifier will let you know when a new ReactQL kit is available. To upgrade the CLI to 2.4.0, simply re-install with npm i -g reactql or yarn global add reactql

Great work @leebenson ! Thank you.
Create React App recently added "Progressive Web Apps". Do you have plans to add this feature as well?

Thanks @mnpenner. Definitely want to explore PWA. Tracking in https://github.com/reactql/cli/issues/40

Kit 1.4.0 has been released, offering Brotli compression via statically compressed .br assets, and improved gzip compression via Zopfli.

Somewhat dependent on #40, but a hnpwa would be a great example project. We would need to build a server, as it doesn't look like graph.cool will handle this use case, but that's not too difficult. @leebenson or anyone else, let me know if you'd be interested in collabing on something like this.

@jtmthf - I've added you as a maintainer to https://github.com/reactql/examples, the new home for examples. It's empty (save for a README/good intentions); I'll be adding to it with some GraphQL server examples and other stuff soon.
Feel free to create any examples you see fit there.
The hnpwa app would be a great one to tackle, post-https://github.com/reactql/kit/issues/31

I've added the first example of running a GraphQL server alongside the existing web server - check it out at https://github.com/reactql/examples/tree/master/graphql-server

FYI, I've added an example that yanks out GraphQL, for times when you need to connect to a legacy REST endpoint instead, or just don't want/need GraphQL in your project.
See: https://github.com/reactql/examples/tree/master/no-graphql
This example also demonstrates the built-in Redux hooks, with a simple to-do component. A to-do gets added on the server, and sent down the wire for location rehydration in the browser. Shows how you can add custom reducers to kit/lib/redux.js alongside/instead of Apollo.

@leebenson Hey Lee! Any plans for built-in support for serverless architecture like AWS Lambda? It seems like it could be a great scalable way to deploy a ReactQL app in production.
I've been trying to get ReactQL working with the super simple https://github.com/dougmoscrop/serverless-http package and had to manually edit the transpiled server.js file to module.exports the koa instance but I'm having trouble and getting ambiguous errors.
Basically we just need a file which can module.exports the koa instance (without listening()) wrapped in the serverless() function.

@scf4 - that should be trivial to do. kit/entry/server.js already exports 'just' the app - it's kit/entry/server_prod.js (in production) that wires up the listener, logs back to the console, etc.
You'd basically just need to replicate that file, but with a call to serverless(app), and then copy kit/webpack/server_prod.js to something like serverless.js but pointing to the above new 'entry', then create an npm script that uses the WEBPACK_CONFIG=serverless env var.
I'm not sure about supporting it in core - if there's enough demand for it, sure, but otherwise it's another option to manage that may have a relatively niche audience. For now, I think it'd make a good project for https://github.com/reactql/examples -- feel free to submit a PR, thanks!

@leebenson thanks! I had to upgrade to the latest version to get the server_prod file, but unfortunately it's not useable on node 6 anymore (AWS Lambda only supports LTS). I think the main culprit is koa static!

@scf4 - all ReactQL code gets transpiled based on the current environment, so generally all project code should work. NPM modules don't get touched, since they should (technically) be fit for consumption in pretty much any environment -- with transpilation handled by their own build scripts.
It looks like koa-send is the culprit; it uses 'bare' async. Looking at its package.json, they're specifically targeting Node 7.6 (i.e. the introduction of native async/await):
{
  "engines": {
    "node": ">= 7.6.0"
  }
}

The simplest fix is probably to transpile everything (including NPM) with a babel-register hook in the kit/entry/server.js script, which should touch everything require() in node_modules, too.
I want to avoid doing that for core, because a) NPM really ought not to be the province of ReactQL project code; packages should be good citizens (although clearly, this doesn't always happen) and b) this is only an issue until October, when 8.0 hits LTS, and c) I want to encourage adoption (where possible) of 8.x for the speed and native async/await -- having a babel loader is a drag on the dev server, etc.
Based on your use case though, I should at least add a section to the docs that explains how to get it running in old versions.
Try babel-register in kit/entry/server.js and let me know how you get on. You might need to also fiddle with .babelrc in the root, or add a custom config to your babel-register require statement to get async working -- in that case, you can just copy and paste it from the webpack config.

The simplest fix is probably to transpile everything (including NPM) with a babel-register hook in the kit/entry/server.js script, which should touch everything require() in node_modules, too.

You shouldn't need to do that. If you just tweak one of the webpack configs to specifically include koa-send it'll transpile just that node module.

@mnpenner - yup, that'll work too (and it'll be faster). babel-register is more of a 'catch all' in case there winds up being a bunch of other packages that need special treatment.

Kit 1.7.0 was released. It adds a Dockerfile for building your ReactQL projects as Docker images, for front-end scalability via Kubernetes, Rancher, etc.

I'd like to gauge the community's opinion on integrating first-class support for Relay Modern. There's a thread at https://github.com/reactql/kit/issues/36 for discussing thoughts.
I'm particularly interested in:

Which you might prefer - Apollo or Relay?
Reasons for the choice
Any technical barriers you've experienced in one vs. the other
Your support for 'dropping' Apollo in favour of Relay -- I'd ultimately like to support only one going forward rather than fragment the kit, with the other relegated to the examples repo.

Would be interested to hear your thoughts in https://github.com/reactql/kit/issues/36

CLI 3.0.0 was released, which temporarily removes Typescript support pending https://github.com/reactql/kit.ts/issues/18
It also bumps to kit 1.8.1, which introduced a pattern for adding custom Redux reducers in 1.8.0 to augment the built-in Apollo store.

Thanks for the advice @leebenson. I just got around to this again, but I can't get the server.js to actually export anything as it's all wrapped up in the Webpack stuff. Any suggestions?

@scf4 - Are you looking at kit/entry/server.js?
It exports a default object containing router (the default route handlers) and app (the Koa instance).
In kit/entry/server_prod.js is where we actually wire up app with the router.
To work with AWS Lambda, you'd need to create something like serverless.js that follows the same pattern- i.e. imports kit/entry/server.js as a base, and then configures it to work with Lambda.
Finally, you'd need to create a Webpack config that transpiles the serverless.js entry point.
If Lambda only supports Node 6.11, you'll need to wait until it's upgraded to > 7.6 for native async/await to land. Otherwise you can configure Webpack to include the Babel async to generator plugin and set it to transpile koa-send along with any other plugin that uses async.

Just a heads-up that I'll be releasing kit v2.0 over the weekend.
The kit will introduce two significant improvements:

The graph.cool endpoint will be replaced with a sample GraphQL server that's built-in to the ReactQL koa web server. This will provide the advantage of demonstrating how to add your own GraphQL schema and respond to queries, in the common scenario where you're building a 'monolithic' web app on a single Node.js codebase. It will also make it easier for you to test against real GraphQL schema, and go beyond the immutable 'Hello from graph.cool' message that the kit currently offers. You'll be able to add your own GraphQL functionality via the next improvement...

The kit will get a new API, with the ability to change settings, add custom reducers, set the GraphQL endpoint, and even add your own Koa handlers, without ever touching kit/* files. You'll be able to do this within src/app.js, via Settings.addReducer() and equivalent functions on a new global class.

This paves the way for super-simple upgrades -- just keep everything within src and use kit API hooks, and you'll rarely need to delve under the hood.
The documentation will also get a refresh, to introduce the new settings API.

@leebenson thanks for the advice regarding lambda deployment again. It really turned out to be a bigger headache than I had time for, and the rendering was much slower than I'd hoped.
My advice for anyone running into hurdles with ReactQL and Lambda would be to save the time and look for another solution.
I'm now running on Heroku (as it's where my API was anyway) and the DX is infinitely better, especially with their CI.
Unfortunately rendering is still fairly slow as React SSR tends to be, but I'll be looking into something like RapScallion for my project.
Have you considered replacing the default rendertostring in this kit? IIRC rapscallion has a ~30% speed boost OTB.

@leebenson

in the common scenario where you're building a 'monolithic' web app on a single Node.js codebase

Will it be easy to separate the two? i.e., run Koa on one server and GraphQL on another?

without ever touching kit/* files

Sounding a bit like CRA now. Not that that's necessarily bad, but I thought the difference was that this was a starter kit and not a framework?
@scf4 First I've heard of Rapscallion. Sounds nice, but before jumping on that, keep in mind that React 16 is due out in probably the next month or two, and as I understand it, it supports streaming-rendering too. Not sure if that'll bring it up to the same speed or not though.

@mnpenner Oh nice, I wasn't aware of the SSR improvements in 16. I'll be upgrading this weekend so it'll be interesting to compare the SSR performance.
If it has comparable performance then perhaps rapscallion wouldn't be worth potentially complicating things for a general starter kit, but I'll likely be using it for my app anyway since it has other features like render caching at the component level.
Since we're on the topic,  perhaps it'd be worth releasing v2 with React 16?
It's fairly close to an official release, but Facebook already considers it stable enough to use in production and has been using it for some time.

@mnpenner

Will it be easy to separate the two? i.e., run Koa on one server and GraphQL on another?

Yep, you'll be able to turn GraphQL on in the built-in Koa server if you wish, or avoid it completely and simply point to an external endpoint that you run off-site.
The API will be quite flexible, without changing the overall layout of a project.

Sounding a bit like CRA now. Not that that's necessarily bad, but I thought the difference was that this was a starter kit and not a framework?

It's still very much a starter kit. I'm simply making the lines between 'kit' and 'app' slightly less blurry, so when a bug fix or another feature is released in a future kit, less surgery is required to inherit the upgrades.

Since we're on the topic, perhaps it'd be worth releasing v2 with React 16?

There's an open PR. I'll do some local testing over the weekend and if I don't run into anything major, will bump to v16. 👍

React 16 checklist is here. I'm not sure if the streaming API has been finalized or not, but there's some documentation on it here.
I guess you can decide if it's stable enough to merge yet or not 😄

Thanks @mnpenner. I've managed to get the streaming API working on the server. Koa natively handles streams, so it was just a case of figuring out the new streaming API; the documentation shown at the link is incorrect (I wound up trawling through source and discovering it was actually just a case of swapping renderToString to renderToStream on the same import.)
So far, v16 is performing perfectly with out-the-box ReactQL components, in all modes. A little too well, actually - I was expecting something would balk, but inline hot reloading, streaming, re-hydration of server generated HTML... all seem to be holding up well.
Maybe v16 is ready 😉  .

Performance looks to be significantly improved in kit v2.0 with React v16:

vs. React 15:

In case you were curious how quickly the ReactQL stack parses the initial request, creates a store, and returns the React render stream:

Speed FTW.

@leebenson awesome! 3x render speeding is amazing.
Would you be able to quickly share a snippet of how you hooked up the streaming API to Koa? I'm launching something with this kit and 16 (or rapscallion if I run into troubles) this weekend and it'd save me some time :)

@scf4 - sure, here's what I did:
First, upgrade react and react-dom to ^16.0.0-beta.3 in your project.
Then edit:
kit/entry/server.js
Add this import:
/* Node */

// For pre-pending a `<!DOCTYPE html>` stream to the server response
import { PassThrough } from 'stream';

Then modify the createReactHandler func to this:
export function createReactHandler(css = [], scripts = [], chunkManifest = {}) {
  return async function reactHandler(ctx) {
    const routeContext = {};

    // Create a new server Apollo client for this request
    const client = serverClient();

    // Create a new Redux store for this request
    const store = createNewStore(client);

    // Generate the HTML from our React tree.  We're wrapping the result
    // in `react-router`'s <StaticRouter> which will pull out URL info and
    // store it in our empty `route` object
    const components = (
      <StaticRouter location={ctx.request.url} context={routeContext}>
        <ApolloProvider store={store} client={client}>
          <App />
        </ApolloProvider>
      </StaticRouter>
    );

    // Wait for GraphQL data to be available in our initial render,
    // before dumping HTML back to the client
    await getDataFromTree(components);

    // Handle redirects
    if ([301, 302].includes(routeContext.status)) {
      // 301 = permanent redirect, 302 = temporary
      ctx.status = routeContext.status;

      // Issue the new `Location:` header
      ctx.redirect(routeContext.url);

      // Return early -- no need to set a response body
      return;
    }

    // Handle 404 Not Found
    if (routeContext.status === 404) {
      // By default, just set the status code to 404.  You can add your
      // own custom logic here, if you want to redirect to a permanent
      // 404 route or set a different response on `ctx.body`
      ctx.status = routeContext.status;
    }

    // Create a HTML stream, to send back to the browser
    const htmlStream = new PassThrough();

    // Prefix the doctype, so the browser knows to expect HTML5
    htmlStream.write('<!DOCTYPE html>');

    // Create a stream of the React render. We'll pass in the
    // Helmet component to generate the <head> tag, as well as our Redux
    // store state so that the browser can continue from the server
    const reactStream = ReactDOMServer.renderToStream(
      <Html
        head={Helmet.rewind()}
        window={{
          webpackManifest: chunkManifest,
          __STATE__: store.getState(),
        }}
        css={css}
        scripts={scripts}>
        {components}
      </Html>,
    );

    // Pipe the React stream to the HTML output
    reactStream.pipe(htmlStream);

    // Set the return type to `text/html`, and stream the response back to
    // the client
    ctx.type = 'text/html';
    ctx.body = htmlStream;
  };
}

I made one slight adjustment to the <Html> component. Instead of accepting a rendered HTML string (and therefore foregoing streaming) and dangerously setting the inner HTML, it'll take components as a child prop and render as part of the final stream:
kit/views/ssr.js
// Modify `Html` to the following

const Html = ({ head, scripts, window, css, children }) => (
  <html lang="en" prefix="og: http://ogp.me/ns#">
    <head>
      <meta charSet="utf-8" />
      <meta httpEquiv="X-UA-Compatible" content="IE=edge" />
      <meta httpEquiv="Content-Language" content="en" />
      <meta name="viewport" content="width=device-width, initial-scale=1" />
      {head.meta.toComponent()}
      <link rel="stylesheet" href={css} />
      {head.title.toComponent()}
    </head>
    <body>
      <div id="main">{children}</div>
      <script
        dangerouslySetInnerHTML={{
          __html: Object.keys(window).reduce(
            (out, key) => out += `window.${key}=${JSON.stringify(window[key])};`,
            ''),
        }} />
      {scripts.map(src => <script key={src} src={src} />)}
    </body>
  </html>
);

Html.propTypes = {
  head: PropTypes.object.isRequired,
  window: PropTypes.object.isRequired,
  scripts: PropTypes.arrayOf(PropTypes.string).isRequired,
  css: PropTypes.string.isRequired,
  children: PropTypes.element.isRequired,
};

Finally, in the browser entry point, change doRender() to use the new ReactDOM.rehydrate() method (since render has been deprecated with SSR):
kit/entry/browser.js
function doRender() {
  ReactDOM.hydrate(
    <Root />,
    document.getElementById('main'),
  );
}

That should get you going.
A nice side-effect to v16 btw, is that the previous data-reactid attributes have disappeared, so the rendered HTML is much cleaner/leaner:

https://github.com/reactql/kit/releases/tag/2.0.0

CLI v4.0.0 released with kit v2.0.0. npm i -g reactql to upgrade.

ReactQL CLI v4.4.0 has been released, which adds reactql upgrade powers to new projects.
All files in the newer kit will overwrite old files (except userland src/*, readme/changelog/license files, and any additional/newer files that you may have added that are not present in the kit), your package.json will be merged with the newer variant, and newer NPM packages will be auto-installed.
See https://github.com/reactql/cli/releases/tag/4.4.0 for the full release notes.
As this is a new feature, common sense applies -- back up your existing projects, and don't rely on it to not screw up your project (especially if you've made changes to any kit files... they will be overwritten.)
This release cements the latest improvements to the kit that make it simpler to keep the majority of code in userland (src/) without touching the kit for common configuration options such as adding routes, setting GraphQL schema, pointing to an external GraphQL endpoint, adding a 404 handler, etc.
(Sidenote: As of the latest kit v2.4.0, the per-request Redux store and Apollo client is added to to Koa's ctx object and available to any later route or middleware you define with config.addMiddleware() or config.addPostRoute(), etc - so you can do interesting things such build REST endpoints that fire Redux actions, and then capture state changes in middleware)
It's the precursor to the full-stack auth example that is coming imminently (the next day or two.)
Hopefully this makes upgrades between kits a little less painful.

it could also be awsome if we could choose between react and preact from the cli

@karev - I'm a fan of preact, but I'm not sure it's something we can support in ReactQL by default. This should probably remain a userland exercise.
There's too much of an ecosystem around react - React Router, Apollo, SSR streaming via React 16, etc - that there may be significant chunks that would be subject to change/maintain, even if preact-compat was included.
AFAIK, the main selling point of Preact is a smaller surface area for browser bundling, but in 95%+ of cases this is negligible (the Brotli browser-side vendor bundle weighs in at 90.4kb for everything - most sites will have JPEGs that are bigger). Are there other compelling reasons I'm missing?

the only reason that make me consider preact over react is the change of the license made by facebook,
https://medium.com/@raulk/if-youre-a-startup-you-should-not-use-react-reflecting-on-the-bsd-patents-license-b049d4a67dd2

I'm not a patent expert, so qualify this statement with professional advice, but I'd imagine the number of companies using React in production would largely mitigate any risk. That includes some very well known billion-dollar companies outside of Facebook.
And if it's an issue, you could switch out for Preact prior to selling your company.
Again, not an expert, but I imagine this is largely a non-issue.

@karev<EMAIL_ADDRESS>

react patent scare campaign is an utter bullcrap from Apache f worried and scared about react community getting too big and the omnipresence of react ecosystem
.@Apple uses React.
@amazon uses React.
@facebook, obviously, uses React.
@Microsoft uses React too.
What then?
https://twitter.com/TomGoldenberg/status/900397048675139585
If FB holds a patent on Virtual DOM then  vue.js will also violate that patent because they also use a virtual DOM.
If you’re a startup you should use React. You’ll save a tonne of time writing a cross platform Web, Android and iOS app
If you ever get to the day that Facebook wants to take you to court (which you will most likely never), it’ll be because you’re already a gigantic success and $$$ is no object to you .
wanna play safe just go use vanilla js ..no one is going to f sue you

With Apollo 2.0 beta, there's an opportunity for ReactQL to adopt 'real-time by default' and do some interesting things not readily available.
Redux could be replaced by end-to-end GraphQL (think: no reducers, just mutations), Websockets could replace vanilla HTTP for server-pushed data. We could even implement a distributed session cache, that survives server/browser refreshes to reload app state.
Would love to hear your thoughts here -> https://github.com/reactql/kit/issues/80

@leebenson Real time by default sounds amazing, I haven't heard about this. Got a link?

@scf4 - Real-time by default = GraphQL subscriptions (via websockets)
The difficulty is making a distinction between queries that need to update for everyone listening, and queries that are specific to the local user. I'm toying with implementing a universal cache that can be combined with the subscription logic, to make it possible to do both.
Apollo v2 introduces custom caches/networking that could make the above a little easier.

@leebenson I'm currently handling that with redis (https://github.com/davidyaha/graphql-redis-subscriptions) and it's running pretty well. Are you widening the scope if ReactQL to include the backend too? If so I might be able to help!

thanks @scf4. ReactQL 2.x already includes the server, but I'm toying with expanding to include patterns for subscriptions, caching and push-data.

https://twitter.com/leeb/status/911385713333039104

maybe include some example of how the write to db process works in this architecture.
an input -> calls a mutation -> app updates with new message

@FinnFrotscher - see the auth example project for a live example of connecting to a DB back-end.

Any plans on upgrading to Apollo Client 2? :)

Any plans on upgrading to Apollo Client 2

Yeah, I'm exploring that now, along with a generally more modular approach to other features of the kit. First step is to convert the kit to Typescript.
No ETA for release, but I'm actively working on it now.

Hey @leebenson, for clarification your direction for this project is to rewrite it in TypeScript and only support TS going forward? I ask because our company decided against TS staying on the ES path (which I suspect will be the case for others) meaning I will need to stop my R&D + recommendation to find another kit. :sob:

@NotJustClarkKent - whilst the kit itself will be written in TS, you can use plain ES6 in your userland code. It will compile both.
This is the pattern many popular projects are now taking - Apollo, Angular, etc. If you import them from a .ts file, you inherit type info automatically. If not, it's just like plain Javascript.
That's the plan, anyway. I'm still exploring patterns for v3.0. One idea I'm toying with is separating out the Webpack 'launcher' from the Apollo/React kit itself, so the two become separate projects. At the moment, when you use the kit, you inherit a bunch of features you may not want - opinionated CSS, image processing, Helmet for headers, etc. This seems like an obvious place to put that extra stuff in some kind of preset, that can be dynamically loaded into the launcher.
Again, still playing around, so nothing is settled yet. But it's likely it'll wind up something like the above. The end effect would be much cleaner code (with a separate launcher, you wouldn't have to drag around the whole kit each time -- just load the pieces you need), as well as TS.
FWIW, as someone who was previously resistant to Typescript, I'd now highly recommend it. Getting type info during development has already caught a handful of hand-to-trace bugs in our production server code and makes development so much nicer. The thought of going back to the wild west of plain ES6 just seems crazy now.

@leebenson I have used and love typescript with angular, quite a bit, so I'm really liking the idea of adding typechecking in there.
I'm currently using flow for that though, because it felt like the more react way to me, since it is widely used for and with react.
But in the end I wouldn't care as long as we have something like that in there. ;)

I like Flow too, but TS is emerging as the standard. Would recommend watching https://channel9.msdn.com/Events/Build/2017/B8088/ for the latest features.

@leebenson @SimonErich we're using Flow here as well. [soap box] I've been at this for 18yrs now and I've seen many technologies come and go related to front end (javascript specifically) and my bet on JS over abstractions like Spider, LiveScript and CoffeeScript has kept me sane and less fatigued than my peers enabling me to be more productive. For what it's worth, we choose Flow based on it's balance of type safety, the fact that we still write native JS and that it can be "eject" from our projects when the next type safe flavour of the month language comes along.[/soap box]
That said, this is your project and I respect the direction you set. Further, I want to underscore my appreciation for you putting so much effort into an open source project and sharing your knowledge with the rest of us. A sincere thank you Lee!

@NotJustClarkKent TypeScript is backed by Microsoft and a lot of other big players have started to adopt it too, so I don't expect it to go away anytime soon. I'd argue its just as ejectable as Flow. Both add type annotations to your code, so either way you're going to have to strip those away. The only difference is that TypeScript adds a few extra niceties on-top of EcmaScript such as enums but they compile away pretty cleanly so I don't expect it'd be an issue. In fact, I've "compiled" a few TypeScript files by hand by just deleting all the annotations and it runs fine.
That said, I've found both languages to be equally fatiguing. Flow complains so hard out of the box that it's crashed my computer when trying to run the typechecker on an existing project. TypeScript is slightly more forgiving I've found, but if you enable strict everything you'll get a ton of warnings until you figure out how to markup your code just-so (which gets into some crazy type theory pretty fast).
In any case, it seems like TypeScript is winning the race (see Flow vs TS) and for me as the consumer I'd rather only have to install type definitions from one source rather than having to figure out which library is using what for the best IDE support.

Thanks @mnpenner I appreciate the discussion and agree with Microsoft's backing of TS it will be around for the foreseeable future, its more the commitment (if I can call it that) to thinks like the .ts ext and what our team perceive to be more intrusive syntax. But again, thanks for the good counter points and interesting material I'll review. I don't want to hijack this thread so I'll leave it there, but again, thanks for the great discussion! Cheers!

I like Flow and I really wish it was doing better than TS, but it's such a pain to set up, not enough libraries have types, and I often get so many errors from npm modules, mismatched Flow version, or something else.
I figured I should give TypeScript a try after seeing this thread and it's just so much more straight forward. I've also recently switched to VS code (mainly for its autocomplete) and it also seems so well put together — at least compared to Atom/Nuclide which feels like a bunch of packages hacked together.
I avoided TS and VSCode because of my dislike of Microsoft's past (particularly when it comes to web development) but I can't deny this stuff is really good.
Anyway, thank you Lee for all your work on ReactQL!

The decision to move ahead with TS comes from recent experience.
Historically, we had a community-led TS version of ReactQL, which I never got involved with. At the time, the surface area of ReactQL was tiny, and I didn't really see the point. After 20+ years with both static and dynamically typed languages, my sentiment was that TS was an unnecessary bolt-on that often got in the way of Javascript's expressiveness -- a half-baked type system that would choke when encountering the majority of NPM packages, and could easily be side-stepped by applying any liberally.
Recent experience has proven the above to be somewhat out-dated view. The latest versions of TS are really quite impressive, and I'm quite amazed at how well it infers complex types -- even recursive, generic types -- that I'd expect from a far more mature type system. There have only been two scenarios where I've found it too easy to unwittingly bypass or trip it up -- when using rest parameters inside an Object.assign and when omitting await on a Promise that hasn't explicitly been set a void return type... both of which have open issues/PRs and are being worked on. Apart from that, whenever TS has complained, it's usually had a good reason to so.
I think a lot of the resistance to TS comes from a combination of:

Many JS developers have never encountered a static type system before, and they just don't see the point in it. Why write extra code to get something to compile, when you could just do what you're used to doing and know it should work?

Out-dated experience with Typescript, when you had to do all kinds of gymnastics to download the right .d.ts files and then discover things didn't quite match up when you needed to actually use the types. (npm i -D @types/* now solves this for the majority of popular libs... and it's easy to type-as-you-go for everything else.)

Disdain for all things Microsoft.

Admittedly, I've fallen into all three camps at some point (although I had plenty of experience with statically typed languages -- most of my back-end systems are written in Go -- it was always nice to fall back to a dynamic language like JS or Python and get the illusion I was being more productive) -- but I now consider TS a boon.
Especially with the surface area of ReactQL increasing... no more "was that method setGraphQLEndpoint or setGraphqlEndpoint or even addGraphQLEndpoint"? Just start typing, and VS Code will tell you / bark at you if you get it wrong.
I also think Microsoft is experience something of a renaissance with their OSS strategy.
FWIW, I think C# is probably the best general-purpose OOP language in the world today... and expect a resurgence in it use in the years ahead due to the fact it can now be bundled in a Docker image. .NET Core 2 adds pretty much the whole .NET framework to Linux/Mac. This can help Typescript adoption; they're very similar. Plenty of projects are also now adopting it as the de facto language for NPM packages. Look at Angular, Ionic, Apollo 2. I'm often surprised after importing a package that types are there, without adding an accompany @types package.
And, VS Code is a really nice experience with Typescript. Real-time checking is extremely fast- much faster than Atom. I can't actually believe how sluggish Atom is compared, until I open it up and try to do anything. Seriously, if you haven't tried VS Code, give it a go.
I realise many of the above arguments could also apply to Flow. It has the backing of a 12-figure company (Facebook), just like TS (Microsoft). It's part and parcel of core libs we already use (React). It's relatively smart and quite fast (although, perhaps out-dated now, there are reports that it can be sluggish at scale.)
Ultimately, though, I feel TS' latest iterations and its growing NPM dominance give TS the upper hand.

https://github.com/reactql/cli/issues/10#issuecomment-343414491 graphql2.0
any update on this front?

@FinnFrotscher - it'll be introduced in the kit 3.0 release. ~2 more weeks.

@leebenson great project, good work. just wondering if there was an update on the kit 3.0 release date?
Cheers :)

Alright guys, a long time coming, but I released 3.0.0 today.
After much back and forth on the approach, I decided to stick to the original ethos, which is offering ReactQL purely as a universal, front-end starter kit rather than a 'framework' with a bunch of abstractions vs. making direct changes to the code. I didn't/don't want to hide any details of what the kit is doing behind a NPM module, or make a distinction between ReactQL and userland code.
Instead, you can just clone the repo, and start coding.
The GraphQL server functionality has been ripped out. That's really easy to add back in if you need it, but I'd generally recommend the server being separate anyway. When you're connecting to databases, third-party APIs, it's easy to bloat the front-end with a bunch of stuff that's really the domain of a separate server, so I've kept this kit lean and focused on one goal: Rendering GraphQL in React.
I've also updated the stack to the latest on offer: React 16.4, Apollo 2.0, Webpack 4. Styled Components has been added, with an included helper lib that makes theming really easy. SASS/LESS/external .css imports are still supported - you can now use both.
The build process has undergone a major overhaul with Webpack 4. Gone are the overly entwined Webpack config files. Now, the server entry point returns React middleware, and it's from that point that the resulting server.js file is built. That allows the Koa web server to be spawned in Javascript and just add the Webpack built file as middleware, dramatically cutting down on what needs to be built on the server.
It also made it much simpler to add hot-code reloading to Koa, so now we have full SSR in both development and production! What's more, the server fully restarts on all code changes, so you get both browser patching and immediate SSR updates on refresh.
I've performed a long-awaited transition to Typescript. The whole kit is written in Typescript now. I realise there are users who might Flow, or even just vanilla JS. That's fine, but I had to make a choice, and Typescript has - for me, at least - provided the best developer experience of any, especially when paired with Visual Studio Code. I feel it offers the more comprehensive typing whilst also (for the most part) being helpful enough to pick up goofs, without getting in the way.
If you'd prefer vanilla JS, you should just be able to import .js files (instead of .ts(x)) and it should just work. I haven't tested this comprehensively though, so YMMV. File an issue if you find anything that's not quite right.
Finally, in case you hadn't noticed, there's no longer a ReactQL CLI. The new home for this kit is https://github.com/leebenson/reactql. Since we're back to the original ethos of this being a starter kit, I wanted to make it very clear that getting started literally just means cloning the repo and laying down some code. The CLI, IMO, made this feel more 'frameworky' and didn't offer any real advantage. So it's gone.
I'd welcome any feedback on the new approach, and kit in general. If you spot any issues, as always, just file an issue.
The motivation for this new kit was to squarely use this as my de facto front-end in a number of client and personal projects I've been working on. Clearly, the previous version of ReactQL was showing its age (over half a year since I'd made any significant changes, which is a lifetime with this fast-moving GraphQL stack...). There were a few things I wasn't happy about, like straddling between it being a starter kit and a 'real' framework, and security issues started cropping up in old pieces of the stack.
This version has been re-written from the ground up. I hope you find it useful.

Thank you Lee, very cool!
On Fri, Aug 3, 2018, 13:17 Lee Benson<EMAIL_ADDRESS>wrote:

Alright guys, a long time coming, but I released 3.0.0 today.
After much back and forth on the approach, I decided to stick to the
original ethos, which is offering ReactQL purely as a universal, front-end
starter kit rather than a 'framework' with a bunch of abstractions vs.
making direct changes to the code. I didn't/don't want to hide any details
of what the kit is doing behind a NPM module, or make a distinction between
ReactQL and userland code.
Instead, you can just clone the repo, and start coding.
The GraphQL server functionality has been ripped out. That's really easy
to add back in if you need it, but I'd generally recommend the server being
separate anyway. When you're connecting to databases, third-party APIs,
it's easy to bloat the front-end with a bunch of stuff that's really the
domain of a separate server, so I've kept this kit lean and focused on one
goal: Rendering GraphQL in React.
I've also updated the stack to the latest on offer: React 16.4, Apollo
2.0, Webpack 4. Styled Components has been added, with an included helper
lib that makes theming really easy. SASS/LESS/external .css imports are
still supported - you can now use both.
The build process has undergone a major overhaul with Webpack 4. Gone are
the overly entwined Webpack config files. Now, the server entry point
returns React middleware, and it's from that point that the resulting
server.js file is built. That allows the Koa web server to be spawned in
Javascript and just add the Webpack built file as middleware, dramatically
cutting down on what needs to be built on the server.
It also made it much simpler to add hot-code reloading to Koa, so now we
have full SSR in both development and production! What's more, the
server fully restarts on all code changes, so you get both browser patching
and immediate SSR updates on refresh.
I've performed a long-awaited transition to Typescript. The whole kit is
written in Typescript now. I realise there are users who might Flow, or
even just vanilla JS. That's fine, but I had to make a choice, and
Typescript has - for me, at least - provided the best developer experience
of any, especially when paired with Visual Studio Code. I feel it offers
the more comprehensive typing whilst also (for the most part) being helpful
enough to pick up goofs, without getting in the way.
If you'd prefer vanilla JS, you should just be able to import .js files
(instead of .ts(x)) and it should just work. I haven't tested this
comprehensively though, so YMMV. File an issue if you find anything that's
not quite right.
Finally, in case you hadn't noticed, there's no longer a ReactQL CLI. The
new home for this kit is https://github.com/leebenson/reactql. Since
we're back to the original ethos of this being a starter kit, I wanted to
make it very clear that getting started literally just means cloning the
repo and laying down some code. The CLI, IMO, made this feel more
'frameworky' and didn't offer any real advantage. So it's gone.
I'd welcome any feedback on the new approach, and kit in general. If you
spot any issues, as always, just file an issue.
The motivation for this new kit was to squarely use this as my de facto
front-end in a number of client and personal projects I've been working on.
Clearly, the previous version of ReactQL was showing its age (over half a
year since I'd made any significant changes, which is a lifetime with
this fast-moving GraphQL stack...). There were a few things I wasn't happy
about, like straddling between it being a starter kit and a 'real'
framework, and security issues started cropping up in old pieces of the
stack.
This version has been re-written from the ground up. I hope you find it
useful.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/leebenson/reactql/issues/10#issuecomment-410223367,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABfrkX3bO8HR9voqqBJ67duhApCEFEZYks5uNDE2gaJpZM4M23P-
.

Oh right - what's up with picking styled-components over Emotion?

Honestly, for the same reason as any X vs Y stack choice: I played with it for a while, and it worked out well.
I don't know Emotion well enough to comment, but my initial impression is they look very, very similar.

Awesome! Will be checking this out, thanks @leebenson


examples/kubernetes: bump cilium-etcd-operator to v2.0.3

Signed-off-by: André Martins<EMAIL_ADDRESS>

This change is

test-me-please

Coverage decreased (-0.01%) to 43.671% when pulling dc5d59cdcac6a256aa3ccef30de32db1dd2d4880 on pr/bump-cilium-etcd-operator into 17f94de6aa84bfa9b86462cad293f2a10bc04286 on master.

test-me-please

test-me-please

test-me-please

test-me-please

test-me-please

@aanm maybe this is failing because of https://github.com/cilium/cilium-etcd-operator/commit/c15b9b2c1276674325d8104cc09143c49682aea3 ? This is the only notable change between 2.0.2 and 2.0.3. I'm not able to discern much from the CI logs, as the failed tests don't collect all the status of all of the pods (including etcd-operator).

test-me-please

@aanm better that than a code issue!


Crash in isRegisteredClass: when running tests

When running my test suite, calling [DDLog registeredClasses] results in a crash in [DDLog isRegisteredClass:] on the line Method getter = class_getClassMethod(class, getterSel); (EXC_BAD_ACCESS). I have updated the registeredClasses method to the newest version because of the reports of numClasses changing (generally I'm running 2.0.0-beta3) but that didn't help. When using the first version of the isRegisteredClass: method that's supposed to not work with ARC in the simulator, I don't get said crash. I am running this in an ARC enabled project on the 8.1 simulator.
This only happens when running tests, in the app proper, it works just fine.
Anything I can do to provide more information or anything I can do to test, please let me know.

This functionality seems to be broken. May be related to #425 as well.

Does this issue still happen? If yes, please reopen it and we can discuss it.

Just ran into the same issue. It crashed at the exact same line when running unit test. I am using XCode 7.3.

@vevo-sterling-li could you add some details here? Look at https://github.com/CocoaLumberjack/CocoaLumberjack/blob/master/.github/ISSUE_TEMPLATE.md for what we would need


missing linked page from Active Directory admin link

"Active Directory admin" in 'Audit to storage destination' section redirects to '404 - Page not found page', please fix the link.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 0c27fe13-a824-84a5-e314-892a27c1dec5
Version Independent ID: 510b5427-c927-84df-563f-31dfe13fc771
Content: Get started with auditing - Azure SQL Database
Content Source: articles/sql-database/sql-database-auditing.md
Service: sql-database
Sub-service: security
GitHub Login: @DavidTrigano
Microsoft Alias: datrigan

Hello @kazshi,
We are sorry for the inconvenience. We update the link accordlingly and you should be able to now have the proper link (https://docs.microsoft.com/azure/sql-database/sql-database-aad-authentication-configure?tabs=azure-powershell#provision-an-azure-active-directory-administrator-for-your-managed-instance)
Changes will be effective in 6/12 hours.
Best Regards,
David T.
SQL Program Manager

@kazshi Thank you for taking the time to report the broken link.
We will proceed to close this issue now.
If there are further questions regarding this matter, please comment and we will gladly continue the discussion.


what kind of LICENSE is this  repo using?

hi, is there LICENSE statement on this repo? thanks.

MIT license


Bug fix: OakRValueBufferImpl will fail if the value moved to a different ByteBuffer

Please also see the added unit-test that reproduces this bug.
Note that the latest PR (https://github.com/yahoo/Oak/pull/84) only escalates this problem.
In the old code, it will only fail if Oak replaced the value's ByteBuffer.
In the latest PR, it will fail for any moved value.

I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.

Can you please rebase it to the newly update master? If yes, I can merge and incorporate it with my PR. So we have this fix inside as well...

I looked over the code and the fix looks good for me

Greate. It is now rebased


Dynamic Configuration Assistant

[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 6f9ce006-d5ab-9155-9019-b329791bcfd2
Version Independent ID: 3b8f6bb8-a499-0bad-d2d7-2e17af1afebd
Content: Special characters - Microsoft Style Guide
Content Source: styleguide/a-z-word-list-term-collections/term-collections/special-characters.md
Product: non-product-specific
GitHub Login: @pallep
Microsoft Alias: pallep

please close this ticket @keonglee1978


Clean up installable-item form not used fields

Codecov Report

Merging #1310 into master will decrease coverage by 0.61%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1310      +/-   ##
==========================================
- Coverage   93.87%   93.25%   -0.62%
==========================================
  Files          44       44
  Lines        4602     4669      +67
  Branches      503      792     +289
==========================================
+ Hits         4320     4354      +34
- Misses        282      287       +5
- Partials        0       28      +28

Impacted Files
Coverage Δ

browser/model/jdk-install.js
93.04% <ø> (-1.01%)
:arrow_down:

browser/model/installable-item.js
92.9% <100%> (-1.91%)
:arrow_down:

browser/model/devstudio-autoinstall.js
97.29% <0%> (-2.71%)
:arrow_down:

browser/services/request.js
97.61% <0%> (-2.39%)
:arrow_down:

browser/pages/install/controller.js
91.86% <0%> (-1.75%)
:arrow_down:

browser/model/helpers/downloader.js
95.53% <0%> (-1.68%)
:arrow_down:

browser/model/che.js
95% <0%> (-1.62%)
:arrow_down:

browser/services/platform.js
97.05% <0%> (-1.41%)
:arrow_down:

browser/pages/account/controller.js
98.61% <0%> (-1.39%)
:arrow_down:

... and 24 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a52a676...818e248. Read the comment docs.


Disable null ls notifications

Hello,
Is there way to disable null-ls(none-ls) notifications? The plugin triggers when formatting a file and I want to disable/ignore everything related to null-ls. Currently my setup is as follows
require("notifier").setup({
  components = { "lsp" },
})

require("notifier").setup({
  ignore_messages = { "null_ls" },
  components = { "lsp" },
})

thank you :)


pegasys does not work with cygwin

Cygwin running on Windows8 64bit
/usr/local/kafka/conf/server.properties

broker.id=<public_dns> instead of integer

/var/lib/zookeeper/myid

cat shows <public_dns> instead of int

(Possibly others, will edit when i find them)

Thanks for the heads up. Pegasus has only been tested on macs and lightly on ubuntu 14.04. I'll be sure to test this on cygwin as well in the future.


Ignore API key file from tutorial

Just a one-line change to the .gitignore, in case users are following this tutorial in a fork or clone of the repo, say, connected to their account. This should avoid the accidental commit of the user's API key to a public repo.
Notice I made this edit from the GitHub UI, and I think it must've automatically coerced the whitespace at the end of the .gitignore as well, so that's why you see two lines changed.

That's a wonderful idea, Blake! I'll make that update in my next set of changes.

Great! Yes, feel free to just copy/paste it in when you need if there's red tape associated with merging this PR directly. I see the Mathworks contributing guide in another of Mathworks' repos requires signing a CLA and all that, which I see is not configured here yet.
I'm really excited about the Python interop, and I'm sure drive-by contributions would be easier if that contribution guide could be ported here.

Right. This seems like an important change, but not worth filling out the requisite copyright paperwork to accept the pull request directly. I will acknowledge your suggestion in the changelog. And if you do get to a point where you want to sign a CLA to contribute something, feel free to let me know. ;)


Molecule doesn't work well with WSL2

My environment:
W10 laptop
WSL2, Ubuntu 20,
molecule           3.0.8
molecule-vagrant   0.3
I can create win2019 VM in virtualbox via Molecule create, but can't reach VM after creation  and configure winrm.
I can run small ansible-playbook to reach from Ubuntu 20 to win2019 VM and create folder.
ssh<EMAIL_ADDRESS>-p 2222 is working too.
but got follow error message.
`
ansible-playbook 2.9.12
config file = /home/silver/.cache/molecule/ansible-role-example-role/default/ansible.cfg
configured module search path = ['/home/silver/virtualenvs/windowslob/lib/python3.8/site-packages/molecule/provisioner/ansible/plugins/modules', '/home/silver/virtualenvs/windowslob/lib/python3.8/site-packages/molecule_vagrant/modules', '/home/silver/.cache/molecule/ansible-role-example-role/default/library', '/home/silver/projects/winlob/ansible-role-example-role/library', '/home/silver/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /home/silver/virtualenvs/windowslob/lib/python3.8/site-packages/ansible
executable location = /home/silver/virtualenvs/windowslob/bin/ansible-playbook
python version = 3.8.10 (default, Sep 28 2021, 16:10:42) [GCC 9.3.0]
Using /home/silver/.cache/molecule/ansible-role-example-role/default/ansible.cfg as config file
host_list declined parsing /home/silver/.cache/molecule/ansible-role-example-role/default/inventory/ansible_inventory.yml as it did not pass its verify_file() method
script declined parsing /home/silver/.cache/molecule/ansible-role-example-role/default/inventory/ansible_inventory.yml as it did not pass its verify_file() method
Parsed /home/silver/.cache/molecule/ansible-role-example-role/default/inventory/ansible_inventory.yml inventory source with yaml plugin
PLAYBOOK: create.yml ***********************************************************
1 plays in /home/silver/virtualenvs/windowslob/lib/python3.8/site-packages/molecule_vagrant/playbooks/create.yml

PLAY [Create] ******************************************************************
META: ran handlers

TASK [Create molecule instance(s)] *********************************************
task path: /home/silver/virtualenvs/windowslob/lib/python3.8/site-packages/molecule_vagrant/playbooks/create.yml:8
<<IP_ADDRESS>> ESTABLISH LOCAL CONNECTION FOR USER: silver
<<IP_ADDRESS>> EXEC /bin/sh -c 'echo ~silver && sleep 0'
<<IP_ADDRESS>> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo /home/silver/.ansible/tmp `"&& mkdir "` echo /home/silver/.ansible/tmp/ansible-tmp-1637589341.9568806-7136-272674182548617 `" && echo ansible-tmp-1637589341.9568806-7136-272674182548617="` echo /home/silver/.ansible/tmp/ansible-tmp-1637589341.9568806-7136-272674182548617 `" ) && sleep 0'
Using module file /home/silver/virtualenvs/windowslob/lib/python3.8/site-packages/molecule_vagrant/modules/vagrant.py
<<IP_ADDRESS>> PUT /home/silver/.ansible/tmp/ansible-local-7118jw9hxuus/tmp1g6rs7_7 TO /home/silver/.ansible/tmp/ansible-tmp-1637589341.9568806-7136-272674182548617/AnsiballZ_vagrant.py
<<IP_ADDRESS>> EXEC /bin/sh -c 'chmod u+x /home/silver/.ansible/tmp/ansible-tmp-1637589341.9568806-7136-272674182548617/ /home/silver/.ansible/tmp/ansible-tmp-1637589341.9568806-7136-272674182548617/AnsiballZ_vagrant.py && sleep 0'
<<IP_ADDRESS>> EXEC /bin/sh -c '/home/silver/virtualenvs/windowslob/bin/python /home/silver/.ansible/tmp/ansible-tmp-1637589341.9568806-7136-272674182548617/AnsiballZ_vagrant.py && sleep 0'
<<IP_ADDRESS>> EXEC /bin/sh -c 'rm -f -r /home/silver/.ansible/tmp/ansible-tmp-1637589341.9568806-7136-272674182548617/ > /dev/null 2>&1 && sleep 0'
The full traceback is:
Traceback (most recent call last):
  File "/home/silver/.ansible/tmp/ansible-tmp-1637589341.9568806-7136-272674182548617/AnsiballZ_vagrant.py", line 102, in <module>
    _ansiballz_main()
  File "/home/silver/.ansible/tmp/ansible-tmp-1637589341.9568806-7136-272674182548617/AnsiballZ_vagrant.py", line 94, in _ansiballz_main
    invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)
  File "/home/silver/.ansible/tmp/ansible-tmp-1637589341.9568806-7136-272674182548617/AnsiballZ_vagrant.py", line 40, in invoke_module
    runpy.run_module(mod_name='ansible.modules.vagrant', init_globals=None, run_name='__main__', alter_sys=True)
  File "/usr/lib/python3.8/runpy.py", line 207, in run_module
    return _run_module_code(code, init_globals, run_name, mod_spec)
  File "/usr/lib/python3.8/runpy.py", line 97, in _run_module_code
    _run_code(code, mod_globals, init_globals,
  File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/tmp/ansible_vagrant_payload_2_l4b3f2/ansible_vagrant_payload.zip/ansible/modules/vagrant.py", line 632, in <module>
  File "/tmp/ansible_vagrant_payload_2_l4b3f2/ansible_vagrant_payload.zip/ansible/modules/vagrant.py", line 628, in main
AttributeError: 'AnsibleModule' object has no attribute 'result'
failed: [localhost] (item=ansible-role-example-role-windows-2019) => {
    "ansible_loop_var": "item",
    "changed": false,
    "item": {
        "box": "jborean93/WindowsServer2019",
        "config_options": {
            "vm.communicator": "'winrm'",
            "winrm.password": "'vagrant'",
            "winrm.remote_user": "'vagrant'"
        },
        "cpus": 1,
        "groups": [
            "windows"
        ],
        "interfaces": [
            {
                "auto_correct": true,
                "guest": 22,
                "host": 2222,
                "host_ip": "<IP_ADDRESS>",
                "network_name": "forwarded_port"
            }
        ],
        "memory": 1024,
        "name": "ansible-role-example-role-windows-2019",
        "provision": true,
        "state": "up"
    },
    "module_stderr": "Traceback (most recent call last):\n  File \"/home/silver/.ansible/tmp/ansible-tmp-1637589341.9568806-7136-272674182548617/AnsiballZ_vagrant.py\", line 102, in <module>\n    _ansiballz_main()\n  File \"/home/silver/.ansible/tmp/ansible-tmp-1637589341.9568806-7136-272674182548617/AnsiballZ_vagrant.py\", line 94, in _ansiballz_main\n    invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\n  File \"/home/silver/.ansible/tmp/ansible-tmp-1637589341.9568806-7136-272674182548617/AnsiballZ_vagrant.py\", line 40, in invoke_module\n    runpy.run_module(mod_name='ansible.modules.vagrant', init_globals=None, run_name='__main__', alter_sys=True)\n  File \"/usr/lib/python3.8/runpy.py\", line 207, in run_module\n    return _run_module_code(code, init_globals, run_name, mod_spec)\n  File \"/usr/lib/python3.8/runpy.py\", line 97, in _run_module_code\n    _run_code(code, mod_globals, init_globals,\n  File \"/usr/lib/python3.8/runpy.py\", line 87, in _run_code\n    exec(code, run_globals)\n  File \"/tmp/ansible_vagrant_payload_2_l4b3f2/ansible_vagrant_payload.zip/ansible/modules/vagrant.py\", line 632, in <module>\n  File \"/tmp/ansible_vagrant_payload_2_l4b3f2/ansible_vagrant_payload.zip/ansible/modules/vagrant.py\", line 628, in main\nAttributeError: 'AnsibleModule' object has no attribute 'result'\n",
    "module_stdout": "",
    "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error",
    "rc": 1
}

PLAY RECAP *********************************************************************
localhost                  : ok=0    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

ERROR: `
Any ideas why Molecule can't reach win2019 VM in virtualbox?

The error handling from molecule-vagrant 0.3 is not so good, leading to a not very helpful message. Can you try git HEAD to see if you can get a better error message ?
Moreover, be informed that winrm connection support is missing, as mentioned in https://github.com/ansible-community/molecule-vagrant/issues/98.

@apatard , I'm so sorry. I'm very new to molecule and others. How to git HEAD to see better error message?
Also, my colleagues working on Mac and they have no issues with Molecule + winrm , is this WSL 2 thing? (also I have trouble with WSL 1).
Are you saying winrm connection is no good for molecule and win2019 and suggest to use ssh instead?
I had a very brief time that when I switch Ansible connection with SSH and then after I tried few things and it's gone. I can't really reproduce SSH connection again.
Are you suggesting I should use SSH on Molecule settings and Ansible settings and rebuild VM in virtualbox?

I've had similar issues with WSL2 and HyperV. For the they turned out to be related to the configuration of the virtual network switches created by Windows. I run a small snippet of PowerShell as a user with administrative rights in order to remedy this:
Get-NetIPInterface | where {$_.InterfaceAlias -eq 'vEthernet (WSL)' -or $_.InterfaceAlias -eq 'vEthernet (Default Switch)'} | Set-NetIPInterface -Forwarding Enable
These changes unfortunately are not permanent. I'm planning on creating a ScheduledTask I can trigger from WSL2 in order to make it permanent unless anybody has a better solution
I hope you solved this problem before and this is just for the next person stumbling over this.


Feedback for “Faq”

Please provide a doc for developer. We are curious about how the project work from a programer's perspective. :)

@voidreaming did you check https://docs.screenpi.pe/docs/plugins
?

what kind of dev doc do you expect?

@voidreaming ?


[feature request] remember Run or Debug choice

It would be nice to remember the last choice of Run or Debug. Currently it's always Debug. Or am I missing any setting?

I believe there's nothing I can do about this, unfortunately. The buttons are generated by VSCode using the package.json as a template. This feature is purely client-side.

Closing this issue due to inactivity.


Return error if multiple implementations are present for one interface

Currently, if there are multiple implementations that satisfy the same interface, Get method will silently pick the first implementation without warning the users. This could be dangerous. In this PR, we're going to modify the Get method to allow it to return an error if that happens.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

@TheJakeSchmidt Updated the code following your suggestions.


Vendor<EMAIL_ADDRESS>and implement ForceDelete method for network extension

How to categorize this PR?

/area networking
/kind enhancement
What this PR does / why we need it:

Vendor<EMAIL_ADDRESS>Implement ForceDelete method for network extension
Add e2e test for force-delete case

Which issue(s) this PR fixes:
Part of https://github.com/gardener/gardener/issues/3110
Special notes for your reviewer:
/hold

~Depends on https://github.com/gardener/gardener-extension-networking-cilium/pull/213~

Release note:

`networking-cilium` extension now supports [Shoot Force Deletion](https://github.com/gardener/gardener/blob/master/docs/usage/shoot_operations.md#force-deletion).

/unhold


tacke file include warnings

Let's see what Codacy is saying about this

Not better, closing here