RCON Connection problem || UNIX

Squad Information

SquadJS Version: V1.1.0
Squad Version: Current

System Information

Operating System: Ubuntu 19.10
NodeJS Version: v14.4.0
Yarn Version: 1.22.4

Description of Issue
Still getting RCON problems resulting in not updating the Teamkill logs >  MySQL & influnc DB
Temp FIX is restarting the bot every 1 hour to be sure..
error: (node:15153) UnhandledPromiseRejectionWarning: Error: Not connected. 14|SquadJS #1  |     at file:///home/XXXXX/SquadJS/squad-server/rcon/index.js:185:16 14|SquadJS #1  |     at new Promise (<anonymous>) 14|SquadJS #1  |     at Rcon.write (file:///home/XXXXX/SquadJS/squad-server/rcon/index.js:179:12) 14|SquadJS #1  |     at Rcon.execute (file:///home/XXXXX/SquadJS/squad-server/rcon/index.js:54:17) 14|SquadJS #1  |     at Rcon.getMapInfo (file:///home/XXXXX/SquadJS/squad-server/rcon/index.js:58:33) 14|SquadJS #1  |     at Timeout._onTimeout (file:///home/XXXXX/SquadJS/squad-server/index.js:56:36) 14|SquadJS #1  |     at listOnTimeout (internal/timers.js:549:17) 14|SquadJS #1  |     at processTimers (internal/timers.js:492:7) 14|SquadJS #1  | (node:15153) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag--unhandled-rejections=strict(see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 4921)
Second error, current SquadJS version:
(node:15153) UnhandledPromiseRejectionWarning: Error: getaddrinfo EAI_AGAIN host 14|SquadJS #1  |     at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:66:26) 14|SquadJS #1  | (node:15153) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict(see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 4929)

The execute methoid in rcon/index.js returns a Promise that can throw errors / reject with an error.
https://github.com/Thomas-Smyth/SquadJS/blob/2b93d0da2c8f78e12aebb3df6abf3a1e8ad3217a/squad-server/rcon/index.js#L54
https://github.com/Thomas-Smyth/SquadJS/blob/2b93d0da2c8f78e12aebb3df6abf3a1e8ad3217a/squad-server/rcon/index.js#L180
Therefore calls to execute should handle rejected Promises.

The execute methoid in rcon/index.js returns a Promise that can throw errors / reject with an error.
https://github.com/Thomas-Smyth/SquadJS/blob/2b93d0da2c8f78e12aebb3df6abf3a1e8ad3217a/squad-server/rcon/index.js#L54
https://github.com/Thomas-Smyth/SquadJS/blob/2b93d0da2c8f78e12aebb3df6abf3a1e8ad3217a/squad-server/rcon/index.js#L180
Therefore calls to execute should handle rejected Promises.

Unfortunately, this is not the root cause of the problem. Whilst error handling is probably something I should improve, it would be good to be able to resolve the cause of these errors.
I know you have supplied it to me on Discord in the past, but are you able to supply some more examples of the RCON verbose logging along with the errors in chronological orders? Furthermore, for some of the errors you have sent me in the past, you were not able to tell me whether it recovered after the error. It would be helpful to have at least one set of logs where it definitely did not recover in order to be able to narrow down the issue.
Based on the logs you have sent me in the past I suspect that RCON commands running between a disconnect and the auto-reconnect reconnecting you somehow breaks the auto-reconnection. As far as I'm aware you are the only one experiencing the issues and I am fairly sure it has not broken for me in the circumstances I describe so it would be really good to get a set of logs to work from.

Logs from @SiDronee:
[1595052031199] RCON (Verbose): Socket Error: connect ECONNREFUSED x.x.x.x:21114
[1595052031199] RCON (Verbose): Error Opening Socket: connect ECONNREFUSED x.x.x.x:21114
[1595052031199] RCON (Verbose): AutoReconnect Failed.
[1595052031199] RCON (Verbose): Socket Closed. AutoReconnect: true
[1595052036201] RCON (Verbose): Attempting AutoReconnect.
[1595052036201] RCON (Verbose): Method Exec: connect()
[1595052036201] RCON (Verbose): Socket Opened.
[1595052036201] RCON (Verbose): Sending auth packet...
[1595052041202] RCON (Verbose): Attempting AutoReconnect.
[1595052041202] RCON (Verbose): Method Exec: connect()
[1595052041202] RCON (Verbose): Socket Opened.
[1595052041202] RCON (Verbose): Sending auth packet...
[1595052041207] RCON (Verbose): Socket Closed. AutoReconnect: true

The connection had been for a while for whatever reason. It then began connecting successfully again but was not able to authenticate and got stuck in a loop of connecting, sending an auth packet, and then disconnecting.
Hopefully, this is enough to begin to try and replicate the issue.

I think this error is similar to the one i'm experiencing on windows
(node:10908) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 768) (node:10908) UnhandledPromiseRejectionWarning: Error: Not connected.     at file:///C:/servers/squadjs-current/SquadJS/squad-server/rcon/index.js:185:16     at new Promise (<anonymous>)     at Rcon.write (file:///C:/servers/squadjs-current/SquadJS/squad-server/rcon/index.js:179:12)     at Rcon.execute (file:///C:/servers/squadjs-current/SquadJS/squad-server/rcon/index.js:54:17)     at Rcon.getMapInfo (file:///C:/servers/squadjs-current/SquadJS/squad-server/rcon/index.js:58:33)     at Timeout._onTimeout (file:///C:/servers/squadjs-current/SquadJS/squad-server/index.js:53:36)     at listOnTimeout (internal/timers.js:551:17)     at processTimers (internal/timers.js:494:7)
We restart the server daily.  Every restart squadjs can't recover and has to be restarted to start to work.

Anything I can do to help resolve this one?  Restarting the bot daily is becoming a chore.

We're having the same issue. If the squad server is either restarted manually, or crashes - SquadJS loses the RCON connection and gets stuck in the AutoReconnect loop which looks like this in the console:
[1602373329932] RCON (Verbose): Attempting AutoReconnect. [1602373329932] RCON (Verbose): Method Exec: connect() [1602373329933] RCON (Verbose): Socket Error: connect ECONNREFUSED <IP_ADDRESS>:21114 [1602373329933] RCON (Verbose): Error Opening Socket: connect ECONNREFUSED <IP_ADDRESS>:21114 [1602373329933] RCON (Verbose): AutoReconnect Failed. [1602373329933] RCON (Verbose): Socket Closed. AutoReconnect: true [1602373334935] RCON (Verbose): Attempting AutoReconnect. [1602373334935] RCON (Verbose): Method Exec: connect() [1602373334936] RCON (Verbose): Socket Opened. [1602373334936] RCON (Verbose): Sending auth packet... [1602373339936] RCON (Verbose): Attempting AutoReconnect.
Only solution appears to be killing, and restarting SquadJS.

Getting config file...
Building Squad server...
Initialising connectors...
Starting discordClient connector...
Loading plugins...
Loading plugin auto-tk-warn...
Loading plugin discord-admin-request...
Loading plugin discord-teamkill...
Watching server 1...
file:///C:/servers/squadjs-current/SquadJS/squad-server/rcon/index.js:181
        reject(new Error('Unable to write to socket'));
               ^

Error: Unable to write to socket
    at file:///C:/servers/squadjs-current/SquadJS/squad-server/rcon/index.js:181:16
    at new Promise (<anonymous>)
    at Rcon.write (file:///C:/servers/squadjs-current/SquadJS/squad-server/rcon/index.js:179:12)
    at Rcon.execute (file:///C:/servers/squadjs-current/SquadJS/squad-server/rcon/index.js:54:17)
    at Rcon.listPlayers (file:///C:/servers/squadjs-current/SquadJS/squad-server/rcon/index.js:67:33)
    at Server.updatePlayers (file:///C:/servers/squadjs-current/SquadJS/squad-server/index.js:108:36)
    at listOnTimeout (internal/timers.js:551:17)
    at processTimers (internal/timers.js:494:7)

The RCON client has been rewritten for SquadJS v2 so I will close this on the basis the issue is most likely no longer present or this existing research will become irrelevant.


[BROKEN] Rewrite container_top tests

On top of #3617

Failure is connectivity issue with ECR
        time="2024-10-30T19:57:47Z" level=fatal msg="failed to resolve reference \"public.ecr.aws/soci-workshop-examples/ffmpeg:latest\": failed to do request: Head \"[https://public.ecr.aws/v2/soci-workshop-examples/ffmpeg/manifests/latest\](https://public.ecr.aws/v2/soci-workshop-examples/ffmpeg/manifests/latest/)": net/http: TLS handshake timeout"```


Bug: app attempts to make too broad of API requests hitting 400

Describe the bug
In https://github.com/open-sauced/api/pull/501 several search and list endpoints were changed to throw a 400 if no topic, repoIds, or other parameter was not provided. I.e., this was added to prevent extremely expensive full table scans of data.
For example, hitting the contributors search endpoint without any filter or query params:
https://beta.api.opensauced.pizza/v2/contributors/search?range=30&width=30

will throw a bad request
{"statusCode":400,"message":"must provide repo, repoIds, topic, filter","error":"Bad Request"}

After #2532, I noticed a few 400s being thrown in insight pages on beta:
https://beta.api.opensauced.pizza/v2/histogram/pull-requests?range=30&width=30

and
https://beta.api.opensauced.pizza/v2/contributors/search?page=1&limit=10&range=30

These latter seem to get re-called with the appropriate repoIds for the page:
https://beta.api.opensauced.pizza/v2/histogram/pull-requests?repoIds=77358263%2C345368765%2C279759605%2C16408992%2C583706111%2C49010787%2C145050544&range=30&width=30

and
https://beta.api.opensauced.pizza/v2/contributors/search?page=1&limit=10&repoIds=16408992%2C583706111%2C49010787%2C145050544%2C77358263%2C345368765%2C279759605&range=30

which return data correctly.
The page still loads fine, so maybe this is a hydration flow problem?
Steps to reproduce

Open networking developer tooling and filter for api.opensauced.pizza to get only our API requests
Go to an insights page
Filter for 400s
Notice the failures

Browsers
Firefox
Additional context (Is this in dev or production?)
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Contributing Docs

[X] I agree to follow this project's Contribution Docs

This histogram one is likely to happen if we make a request before the params are set. I'll take a look


Create id and data.

Implemented changes manually.

That becouse he used github online editor


Prevent invalid mqtt birth topic crashing node-red

fixes #3865
Types of changes

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)

Proposed changes
ensure done is present otherwise call node.error
NOTE: upon connect, when a birth message is sent, the context in which execution arrives at the done call is from within the callback of the MQTT client connect (not within the context the node-red node) meaning there is no done callback to call.
Checklist

[x] I have read the contribution guidelines
[ ] For non-bugfix PRs, I have discussed this change on the forum/slack team.
[x] I have run grunt to verify the unit tests pass
[ ] I have added suitable unit tests to cover the new/changed functionality

Coverage decreased (-0.01%) to 68.328% when pulling fbde0091de47a8393e8e541bebc973b51fa0f721 on Steve-Mcl:fix-mqtt-birth-bad-topic-crash into a5d7f7acceb4c77d1e91feca63a3619164d8b06b on node-red:master.


Add back NotFoundException for BC

As per the discussion here: https://github.com/php-http/discovery/issues/62#issuecomment-229590727

👍 Good, I had just one minor question.

looks good to me. squash and merge?

Yup, but rebase first.


Update MD file on new branch 2017-12-06_13-35-10

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestCon1.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Dev CLI Docker broken in v1.2.0

Docker version of archwayd currently does not work on any platforms.

This file details the differences between using Docker vs local archwayd for queries
This file details the differences between using Docker vs local archwayd for txs

This is fixed!

Fixed in #101


Added article to guide Patterns and Practices for SPFx Development

Category

[ ] Content fix
[x] New article

Related issues

none

What's in this Pull Request?
Added article to guide Patterns and Practices for SPFx Development. It helps to write beautiful and consistent code for SPFx solutions by implementing best practices.

Docs Build status updates of commit 8b881a6:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs/spfx/spfx-patterns-and-practices.md
:warning:Warning
View
Details

docs/spfx/spfx-patterns-and-practices.md

Line 224, Column 68: [Warning: hard-coded-locale - See documentation] Link 'https://docs.microsoft.com/en-us/javascript/api/sp-core-library/servicescope?view=sp-typescript-latest' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 224, Column 68: [Suggestion: docs-link-absolute - See documentation] Absolute link 'https://docs.microsoft.com/en-us/javascript/api/sp-core-library/servicescope?view=sp-typescript-latest' will be broken in isolated environments. Replace with a relative link.
Line 224, Column 68: [Suggestion: preserve-view-not-set - See documentation] You've pinned this link to a specific version of content with the view parameter. It's recommended not to pin a version unless that version is A) not the default view and B) the context is about that version specifically. To proceed with pinning a version add the &preserve-view=true to the URL.  Otherwise, remove the view parameter. URL: https://docs.microsoft.com/en-us/javascript/api/sp-core-library/servicescope?view=sp-typescript-latest

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit e730b67:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/spfx/spfx-patterns-and-practices.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

I'm unclear as to the point of this. Lots of opinions and guidance... is this coming from MS or just your opinions? Where is this referenced/linked from?
As this is a new article, defer to MS for merging.

@andrewconnell Those are my own opinions based on experience.

Docs Build status updates of commit 21bf3e3:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/spfx/spfx-patterns-and-practices.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Thanks for clarifying... while the contribution is appreciated. If you take this to the logical conclusion, there could be many different opinions from individuals on different coding styles... so should they all be backed in this page or multiple pages.
The official SPFx docs are not intended for individual opinions. Rather they're for documentation or guidance coming from Microsoft. I'd suggest you post this to your own personal blog or other community sites.

Thanks for clarifying... while the contribution is appreciated, if you take this to the logical conclusion, there could be many different opinions from individuals on different coding styles... so should they all be backed in this page or multiple pages.
The official SPFx docs are not intended for individual opinions. Rather they're for documentation or guidance coming from Microsoft. I'd suggest you post this to your own personal blog or other community sites.

Thanks @andrewconnell. I expected that coming. I was actually awaiting this kind of guidance from MS only but I couldn't find in sp-dev-docs so thought to contribute here and make it reach broader audience.


Mark createStore as deprecated

We don't want anyone using the core createStore method directly in their apps today. We want them using configureStore from RTK instead.
We should tag createStore as @deprecated on both the 4.x and 5.x branches, and do another 4.x release.
edit
After a bunch of discussion, it's become clear that a lot of people aren't familiar with what RTK actually is, or what the technical differences are between the core createStore API and RTK's configureStore.  Let me provide some background resources.
First, I had a chance to do a livestream with Jason Lengstorf where we explained what people disliked about Redux historically, and how RTK was created to solve those issues.  We then built a small example app with RTK+TS:

https://www.youtube.com/watch?v=9zySeP5vH9c

Next, the "Modern Redux with RTK" tutorial page shows the differences in usage between "vanilla" Redux and RTK for things like store setup and writing reducers:

https://redux.js.org/tutorials/fundamentals/part-8-modern-redux

And for a lot of additional background on why RTK was created and how it evolved, see my "Redux Toolkit 1.0" announcement post.
For the actual technical differences, Lenz had a very good explanation on Twitter today:

In short: configureStore calls applyMiddleware and combineReducers for you and sets up the devtools, all while having a more "sane" api than createStore. For that reason alone, it should be a technical successor of createStore.
In dev, it also adds two additional middlewares per default (middleware added by configureStore is freely configurable): One checks for accidental store mutations, both between renders as well as inside the reducer.
That means it eliminates a whole class of bugs that only surface in "UI sometimes not rerendering" or things "being out of order some time later" - hard and frustrating to find. The other warns if you put non-(de)serializable values like classes into the store.
Not only do these make a lot of problems with the devtools or libraries like redux-persist, even something as simple as a Date instance can mutate itself out of the normal Redux data flow.
So, even if you were not to use the rest of RTK (which still makes you life a lot easier beyond that, removing the need for action types and manual immutable logic), it would still be a good idea to install RTK and use only configureStore out of it, instead of createStore.

There's some comparisons of the before and after setup here:

https://redux.js.org/usage/configuring-your-store
https://redux.js.org/tutorials/fundamentals/part-8-modern-redux#store-setup

Just a first wording suggestion:

 * @deprecated
 * In most cases, you should be using the `configureStore` method
 * of the `@reduxjs/toolkit` package instead of calling `createStore` directly.
 * As `configureStore` is calling `createStore` internally, it will not be going
 * away, and your code will continue working but if you are just starting a
 * new project, please be aware that we recommend using the official
 * Redux Toolkit for any newly written Redux code since 2019.
 *
 * You should not be using this in a new project or when following a tutorial,
 * except for learning purposes.

Hmm, I don't really think this is a good idea for the core library. It's not truly deprecated; we're not getting rid of the API. This is giving the false impression this API is going away.
Also, I don't really think it's our job to tell users how to use the library. If they want to do dumb, bad, illogical things with it, that's up to them. As long as we're pointing them in the better direction of RTK everywhere else, that's what we should focus on.

The problem is that this is essentially the last resort how we can "contact" users that either never revisited the documentation or are following outdated tutorials.
Honestly, I'm less concerned about users that never revisited the documentation: it's on them.
But I deeply care for users that are learning from an outdated tutorial - or from e.g. a bootcamp where the teacher is still teaching vanilla Redux because they never revisited the documentation.
They are not "at fault" here, but are being steered in a very wrong direction and deeply hurt as a result. And there is no other way to contact them than a "strikethrough" in the editor at this point. We will not be able to reach these users by an extra bright-red warning on the homepage or 10 new points in the style guide.
But to keep Redux relevant, we have to reach them.
I would be very fine to add another non-deprecated createStore__iKnow or something for people that really want to use createStore and don't want to see the @deprecated message.
But I am very convinced that we need to step up to this "next level of communication".

Is it really a problem that people are using Redux directly without RTK?   It's not really up to the library to judge how I use it.
This is also an issue that naturally ages out over time. As those outdated tutorials get more and more outdated, they get seen less and less.
There are plenty of old React tutorials still suggesting React.createClass() usage, but the React team hasn't put a warning on that API. Just because it's no longer the best way to use the library doesn't mean it needs to get marked as deprecated.
At the very least, I'm against this because it hijacks the usage of @deprecated in the code. What happens when we want to actually deprecate things? Now it's confusing to know which is which.

I spend time in Discord every single day. I see people struggling hours and days to wrap their head around concepts they don't need and having actual frustration of pain they would not have to have.
And honestly, telling someone about that afterwards is not a nice conversation to have.
In the last two years I have observed hundreds on Discord, another few hundred on Twitter and yet another few hundred on StackOverflow. And those are only the places I am looking. Those are the places where knowledge of Redux Toolkit already has spread and yet, still people are going a painful way. Not because they have a way of choosing, but because they do not know better.
One of too many examples:
Stephen Grider's horribly outdated "Modern React with Redux Training Course" on udemy had at this point 260.000 people taking it, with 75.500 mostly positive reviews averaging at 4.7 stars.
Even if the next 10.000 users would give it 1 star, it would stick around for another year without losing it's top spot.
And people are not giving it one star because he explains Redux-Form (which is deprecated on the homepage of Redux-Form, on the github page and in the npm README since 2019) nicely. They think they learn relevant information. They don't.
And to add insult to injury the course author regularly does minor changes to the course so it is "recently updated" and more people will fall for it. He knows about Redux Toolkit for years now and has chosen to ignore us trying to contact him.
People not only buy into this shit, they also fall victim to the sunken cost fallacy. They already have put money and lots of time into this course, so they will keep following what they learned there. At that point I can tell them that I am a Redux maintainer and that they learn outdated stuff and a good chunk of these people goes on for days, weeks and even multiple months until they come around to try RTK. (And then almost nobody goes back. I think I've seen three people go back so far to vanilla Redux, out of all those hundreds.)
I have spent the last few years telling every single person that they are learning from outdated sources. I spend at least half an hour each day (realistically: probably more around two hours) going through twitter, StackOverflow and Discord telling people. Thinking that this "naturally ages out over time" at this point is naive. I have tried. Mark does too.
It will not happen within the next 2, 3 or 4 years.
The current situation actively damages the reputation of Redux because to this day people tell the story that Redux has a lot of unneccessary boilerplate and that they would rather chop their arm off than take another stab at it.
We can do more to change that.
Adding a deprecation warning is the least we can do. Also, I do not agree that we are hijacking the intended @deprecated usage.  @deprecated does not mean that something will disappear anytime soon. Only that it is outdated and not recommended. In the spritit of "not breaking the web", deprecated browser features sometimes stay around for decades after their deprecation.
A deprecation tag alone says nothing unless the person seeing it also reads the deprecation message attached to it. We can be very clear in our messaging there that createStore is a fine function to use if you need very low level control and want to do things by hand, but that we are nowadays recommending alternatives that are better suited in almost all cases.
But newbies would at least get an indicator that they are wasting their time.

I'm inclined to agree with Lenz here.
This doesn't prevent anyone from using createStore. All existing and new code will work fine.
But we really don't want people using it directly today.
This would at least give a visual indication to users in their editors that we encourage use of RTK instead.  And frankly, as far as I can tell a majority of learners are coming into Redux without seeing that RTK exists, even today.

Hi, I'm chiming in because why not. I've used redux since 2016, I saw Mark posting about rtk last year or something and I've opted to not read it beyond the homepage cause it didn't interest me. I don't consider myself a newbie or a complete dumbass I hope.
But that doesn't mean using createStore is wrong. I like to create my own store and tooling around it. Sure it's not standard but I build hooks with react and custom middleware that fulfils my usecase well. Redux was always a simple core library and essentially telling everyone that if you want to use it directly means you're wrong then that just isn't right.
Yes redux has initial boilerplate cost and maybe it's complicated for new Devs but please, deprecation as a means to encourage rtk is not the correct move, that's not real deprecation unless you really plan to remove createStore some day. The right tool should be used for the job. Update the jsdocs to tell me to use rtk if I want an easier life but don't deprecate the API just because you don't like people using it.
Honestly it makes me sad how opinionated the JS ecosystem has become.

I am personally against this proposal, deprecation of such function might send the wrong message. What about projects that use redux without react?
I used and introduced redux on react-free applications. By deprecating such it's like saying to people that redux must be used with react, which is not correct IMHO

If this is about the word "deprecation", we can happily also just add a runtime console warning that is visible in dev on every app start and can be disabled by setting global._IReallyWantToUseVanillaRedux.
Or we deprecate it with intent of future removal and add a __internal_createStore function in the next version.
Tbh., I'd be fine with that, too. I just don't think it's necessary.
Let's be real: Every other way of telling the users will be more disruptive than a strikethrough in the editor.
@Brianzchen I hope you don't take it personal, but you have just now given a prime example why that warning should be there:

At the point you have heard the first time about RTK, it has already been the officially recommended approach for any newly written Redux code for two years.
When you heard about it, you didn't check it out much further.

You also have the impression that this is just about initial boilerplate cost and not a massive improvement in day-to-day use and reduction of potential bugs.

Also, those subscribed to this issue might have noticed that there was one more comment here that was deleted by the author again. The author expressed anger because now Redux would become "all about React". Clearly the messaging that the RTK core has nothing to do with React and should be used by everyone independently of Framework did not get through there in the past three years.
Taking a step back, frankly Redux is probably one of the only libraries I can think of that did not introduce a breaking change to make life for their users easier because an old core api was replaced with a newer, more user-friendly one.
Thinking about libraries I am using in the ecosystem:

Apollo has done so in what feels like almost every major version.
Material UI has breaking changes left and right. (As most UI libs in general have regularly.)
React Router had really breaking changes, because their approach shifted.
React itself has had big paradigm shifts and they did officially declare mixins as harmful.
RxJs had massive api/usage changes as well.

Those are just what comes to mind.
Maintaining a library is also about finding better ways for our users to use it. About giving them better ergonomics.
This is nothing to be fearful of. Yes, the old stuff still works. That doesn't mean there isn't a better way of doing it and maybe we should help our users to find the right tools instead of going "yeah there are docs here, if they don't read them it's their own fault".

I really like that you authors care about the users, and I share the same sentiment.
There's also the fact that if people still rely on old documentation or don't care about updating themselves, it means that they don't care about the software they intend to use, or to be more specific, they care only about the software they intend to use to begin with, and redux might not be among them.
Software changes and it's harsh, sometimes. If the change brings positive outcome in the long run, so be it.
I think this is a good move and you should go ahead. RTK is more newbie friendly and lowers the barrier to adopt redux.
It could be called "archived" if deprecated is not the right wording. Or a warning might work too.

@zdhr have you read the suggested deprecation message above?

As configureStore is calling createStore internally, it will not be going away, and your code will continue working

The fact that you're considering this approach gives me faith in the library as a whole going forward. Using @deprecated is essential because it provides VSCode users with a strikethrough on the createStore() func.
I'm sure you'll do this too - but I'd recommend adding a long-form section to the docs with why this approach was taken and link it from the comment.

Yep. That's exactly the idea here.
As seen in this thread and the responses to my tweet about this, there are definitely plenty of people who are still using vanilla/legacy Redux in existing apps today. We are not going to break anyone's code, even if/when we release a new redux major version. Period.
But...
We explicitly do not want any new learners adopting those practices today.  And unfortunately, many learners never even think to look at our docs.  Given the prevalence of all these horribly outdated courses and tutorials even today, adding a @deprecated flag is the only way we have to communicate this warning to people who otherwise will likely never hear of RTK in the first place.

For the record, we did previously discuss the idea of moving the existing APIs into a @reduxjs/core package and moving what was then "Redux Starter Kit" into the redux package. But, that was all the way back in late 2018:
https://github.com/reduxjs/redux/issues/3321
I'd really still prefer to not go that direction today.  We already did one big package rename from redux-starter-kit to @reduxjs/toolkit.  We have a ton of docs and templates that refer to @reduxjs/toolkit.  Additionally, shuffling packages would most likely require trying to merge all the separate Redux projects into a single monorepo, which in turn would lead to having to completely redo all the docs sites.  (I've very briefly considered trying to have a single consolidated docs site so all the material is in one place, but the need to have a monorepo so all the content is in one place is basically a showstopper - that's just too much time and effort.)
Adding a single visible indicator to one API method is the lightest action we can take without requiring prohibitive amounts of effort on the part of either maintainers or users.

I'm not sure if this is a useful comment, I clicked around the first tutorial presented in the docs, and the first example I landed on was using createStore. https://github.com/reduxjs/redux#basic-example . The example right after of course offers the simplicity of toolkit, but I think it'd be quite useful to make that more prominent in the docs. The same deprecation note as a highlight in the docs would go very far.

@gkatsanos This is likely an oversight. The getting started page has redux toolkit in the most prominent spot:
https://redux.js.org/introduction/getting-started

I am maintaining an alternative Redux utility library called redux-preboiled. I am sure there are other several alternatives to Redux Toolkit that do not have their any createStore wrapper.
To me, a deprecation of createStore would make no sense at all. Telling users that they literally cannot use core Redux without a deprecation warning unless they use Redux Toolkit strikes me as extremely weird. In fact, it feels like pressuring the user to use Redux Toolkit, for no technical reason whatsoever.
It would be more honest to simply roll Redux Toolkit into Redux and require them to be used as a whole. A pseudo-deprecation, on the other hand, feels to me like keeping up only the faintest illusion of a choice of utilities on top of core Redux, while in fact discouraging everything but Redux Toolkit so heavily that the choice might as well not exist.

@denisw tbh that is the point.  We want people using RTK, and for very good technical reasons (avoiding common bugs, etc).
I do respect that power users like yourself have built your own approaches on top of the Redux core, and we don't want to take away your ability to do that.  That's why I keep pointing out that we're not going to break anyone's existing code.
But to be frank: while the explosion of early interest in Redux resulted in a giant ecosystem of addons, it's become extremely clear that what today's new Redux learners benefit from most is a single standard approach to learn and use.  Having dozens of libs for generating action creators, and other similar behavior, is confusing rather than helpful.
As maintainers of both the Redux core and RTK, and the people who spend countless hours on a daily basis answering questions from people who are learning Redux, we see the problems that both learners and "typical dev" users run into all the time.  RTK was designed to solve those problems... and it's succeeded.
So yes, from our perspective, we are trying to "eliminate the choice" in a sense, because we're trying to guide our users into a path that solves their problems before they even know those problems exist.
This is a delicate balance to strike here, and we're trying to take all potential use cases and constituencies into account.  But in the end, we have to take the steps that we feel will result in the best possible experience for the largest possible portion of our userbase.

@denisw don't you think that people might actually be reading the deprecation note? This whole discussion is so much hate around that one little tag, not around the text after.
Besides that: even Redux-Preboiled seems like it would massively benefit from using configureStore instead of createStore for store setup and just ignoring the rest of RTK.

I'm not "hating", I just find it important to point out that this is a misuse of the concept of deprecation. And while I'm sure many will read the note, it will still look like a problem to use createStore - that the code will break - while this is not the case. Editors will highlight the problem; linters will report it; static analyzers like SonarQube will flag it; and all despite there not being anything to fix.
I guess it will fulfill the purpose of making users aware of Redux Toolkit, and I understand that this is important to guide newcomers in the right direction. But to those that do not Redux Toolkit on purpose, this may have leave a bad taste, and may even feel like a "dark pattern" to push Redux Toolkit on them.
To be clear, it's not a lack of choice that I find problematic. I would be happy to see Redux Toolkit's features being rolled into Redux, even though this would make Preboiled effectively obsolete (RTK is quite similar and more full-featured anyway). What I think annoys me is the pretense of choice combined with questionable nudges like this one; this is what I meant with it not feeling honest.

@denisw : as I mentioned above, we've had a couple prior discussions around the idea of shuffling the packages around, but those would both require a ton of effort and be more confusing to end users.

it will still look like a problem to use createStore

That's... still the point :) From our perspective it is a problem.
It's much like React's deprecated lifecycles.  componentWillReceiveProps still works. But it's a pattern the maintainers are specifically recommending against using, and it prints warnings if those functions exist. To avoid the warnings, you specifically have to effectively acknowledge that "I understand this is not the recommend approach, and I'm okay with that", by renaming it to UNSAFE_componentWillReceiveProps.
So for createStore, this situation seems exactly like the definition of "deprecation"  to me:

deprecation is the discouragement of use of some terminology, feature, design, or practice, typically because it has been superseded or is no longer considered efficient or safe, without completely removing it or prohibiting its use. Typically, deprecated materials are not completely removed to ensure legacy compatibility or back up practice in case new methods are not functional in an odd scenario.  It can also imply that a feature, design, or practice will be removed or discontinued entirely in the future.

Frankly, this is a sort of no-win scenario for us:

Do nothing: continue to have tons of users get pushed into legacy Redux patterns, not even know that RTK exists, and end up with codebases that are buggier and full of boilerplate code and think that is "how Redux should be used"
Shuffle packages around: have a subset of power users yell at us because they're now getting more deps and APIs than "they feel they need"
Mark createStore as deprecated: have a subset of power users yell at us because they're still using createStore, but at least there's a chance that other users will learn about RTK as a result

I understand the complaints being raised in this thread and on Twitter, but at the same time I'm kinda confused at why you and a few others are saying that this feels like a "questionable nudge" or "crying wolf".
Is it because we're talking about labeling createStore as @deprecated without planning to remove the API?  Would it somehow be better if we said "this is actually going away completely and all your existing code is gonna break unless you switch to RTK right now?"

@denisw that's why I already suggested a potential second export with a different name, without the deprecation note.
In the end, this change will end up as

users sees deprecation note
user reads deprecation note
user makes the conscious and educated decision to either use createStore__noDeprecationWarning or use RTK.

So for users who want to keep the current behaviour without a warning, it's a single code change. For a lot of other users, potentially eye-opening.
Mark already quoted the Wikipedia page on "deprecation" on Twitter, but I'm going to do it again here:

"the discouragement of use of some feature or practice, typically because it has been superseded or is no longer considered efficient or safe, without completely removing it or prohibiting its use"

We are 100% within the boundaries of that.

So back to the original point of this thread.
My proposal atm would be:

Add a @deprecated tag to createStore
Add a new Redux core docs page that very clearly spells out "RTK is how we want people using Redux today. createStore is not going away, but we advise against using it or writing Redux logic by hand".
As part of that @deprecated tag, have a message similar to what Lenz wrote at the top of the thread, and link to that page for more details.
Also add export const createStore_legacy = createStore, with no deprecation warning. This would be equivalent to React's UNSAFE_componentWillMount. It runs, same behavior, but no deprecation notice.
Publish this as Redux 4.2.0 .

If users do nothing, their code still runs 100% as-is. They just see a strikethrough version of createStore if they look at that file in their editor, and possibly get a notice if they're actually set up to do a code quality scan like SonarQube.
If that bothers them, they change one import name, and having acknowledged the fact that this is not the approach we want them doing, continue on their merry way, again with no code breaking.
I'd still prefer to avoid any further package shuffling shenanigans, if only because I'm lazy and that promises to be a gigantic amount of work I'd rather not take on :)  But, I'm at least open to having a completely separate thread that revisits the idea of moving packages around to at least see what people's thoughts/ideas are there, with the understanding that it's still a hypothetical thought exercise with no immediate plans to actually change the status quo.

The way I see it is that the main appeal of base redux is at the very core of the 'boilerplate' people complain about: simplicity. RTK is an opinionated API layer, which promotes way more answers than questions were asked. Do I need that query stuff? Do I want to trigger side effects from component code at all? Do I want action creators or POJO actions? Do I want to define my event types? Do I want to use immer to avoid the spread-hell, or something else, like deep assign()? Do I want a general setter action when the user actually sets stuff? Do I want to use react as a 'glorified templating engine' and move business logic to middlewares, which can be easily migrated into state machines? (I do)
Lots of questions from which a few not compatible with RTK is enough for a dev to decide not to use it. I think the core motivation to not wanting people to use the base version is at least questionable. I see the 'custom solutions/onboarding problem' argument questionable too: I've seen so many unpleasant code bases where the dev tried to follow the 'recommended way' in every corner, but it eventually led to many implicit decisions. (A typical case is reaching out to APIs in an ad hoc way, without thinking in patterns.)
I also disagree with the semantics bending about the term 'deprecation'. The WP article mentions the 'removal' aspect permissively but I'd say it's the typical usage. It's also typical to deprecate something in favor of an alternative on the same abstraction level.
The honest version here would be to separate the 'redux' and 'RTK' brand, and focus on RTK in your discord etc. activity. That way you wouldn't be bothered by people using redux.

It's interesting that you have investigated consolidating the packages, and ultimately shelved it as an arduous task that would require significant maintainer time investment. It sounds like if it were a one click merge, you'd have done it by now.
From what I'm reading, it feels like the most consternation is around consumers being strong armed into using an opinionated api layer they feel like they shouldn't be shamed into using.
Is there an option to middle ground, now or in the future, where you don't blend the entire RTK but just port over what's needed for configureStoreto work. At which point this becomes a true proposal for deprecation with an internally supported replacement.
For right now that doesn't change much except perhaps the deprecation notice becomes an official "we are looking at ways to actively remove this as a public api, and replacing it with parts of RTK, but we're still working on the details"
Perhaps this doesn't solve for "we want to teach people to use RTK", but it also feels like pinning all those hopes and dreams onto a single deprecation notice is unrealistic, and would have to be considered as one step in a many layered plan.

@sarimarton :
FWIW I don't think I'm "bending semantics" at all.  What I'm describing exactly matches the Wikipedia definition I quoted: "discouraging use of a feature because it's been superseded, without completely removing it".

The honest version here would be to separate the 'redux' and 'RTK' brand, and focus on RTK in your discord etc. activity. That way you wouldn't be bothered by people using redux.

That really isn't going to happen, for multiple reasons.  To us maintainers, RTK is "Redux" today.  At the same time, we do have a responsibility to anyone using any Redux-related package.  People are not going to stop asking questions, and we're not going to ignore questions just because they're using older practices. But trust me, it's realllly tiring to see yet another user posting a question in Discord and asking why their UI won't update, when RTK would have prevented that problem from ever happening in the first place.
@eddhurst :
This goes into both the historical background of how long Redux has been out there, and the "power users" who are using the Redux core by itself and don't want anything else (ie, several of the people commenting in this thread).
As I've said several times: we're not going to break anyone's code.  Even when we put out major versions of our libraries, we aim to keep any potential changes to an absolute minimum.  Sure, by the rules of semver we'd be totally clear to rename createStore to legacy_createStore with no fallback... but doing that would needlessly break valid running code. We're not going to do that.  So, no, we're not removing createStore.  But we do want to actively raise awareness of RTK, and nudge people to move over, just like React did with the UNSAFE_* lifecycle changes.

I don’t think it makes any sense to have a library be installed where the main entry point is deprecated. If the maintainers intend for a different library to be used, then deprecate the whole thing and recommend the other library. Having to install RTK just to use configureStore just doesn’t make sense to me. The redux package just wouldn’t stand on itself anymore. It seems that the maintainers want to keep the popularity of Redux, while forcing everybody to use RTK, without paying the maintenance cost of making Redux itself evolve to provide RTKs features.
RTK is a different thing. It uses the Redux core internally, but it’s a different thing. Deprecating the core’s entry point just to push people to use RTK would leave a horrible taste in a lot of devs mouths, I think.

There's a lot of debate here about semantics. At the end of the day, the idea here is to add a comment to the source code, as a way to encourage users to use the preferred tooling for the library, without breaking any existing code. There wouldn't be any console warnings, just a subtle visual indicator in certain IDEs that can gently nudge devs to investigate. Especially given the fact that there could be an alternative entry point that points to the exact same function and doesn't have that comment, I really don't see any real reason to oppose this.
I've been working with redux for years and the only reason I found out about RTK was because I happened to see Mark post about it on twitter. But I would absolutely fit into the target audience for this change, in the sense that if I hadn't already heard about it, but I saw that createStore was marked as deprecated, I would inspect the depreciation warning and look into RTK and embraced it. Adopting RTK has made my life much easier and our codebase much cleaner, and I have found and fixed multiple existing bugs directly because of it.
So in short I'm strongly in favor of this proposed change, largely because if it had been there a year or two ago, I would have been able to avoid a lot of headaches because I would have heard of and adopted RTK much sooner.

Given the discussions in this thread, I've just published a new Redux docs page:
Introduction > Why Redux Toolkit is How to Use Redux Today
It includes:

A review of what "Redux" really is (store, actions, reducers + immutable updates; optionally, standard patterns like thunks, normalization, selectors, DevTools)
A look at what the redux core package actually does and does not provide
A look at what the @reduxjs/toolkit package provides and how its APIs help cover the standard use cases commonly seen in Redux apps
A more specific explanation of how we recommend RTK as the default standard approach for writing any Redux logic, and how RTK solves the problems that users have experienced over the years from following "boilerplate"-y patterns and hand-writing vanilla Redux logic

Hopefully this helps clarify some of the mindset here, and shows that Redux Toolkit really is "Redux", just improved.

Just read the new docs page explaining RTK and its benefits over core Redux. Good job in that page, it's very well written.
FWIW, after reading it I still came out of it feeling like I've felt in the past when I've read about RTK: looks great, specially for beginners, but I prefer vanilla Redux. I'll share two reasons here. First, createSlice is biased towards a 1:1 relationship between reducers and actions while Redux has always been about a 1:n relationship between reducers and actions. Second, immer is great and getting it for free with createSlice is nice but there's a cost associated with that: bundle size. Now, for most applications that difference would make absolutely no impact. But no one here's arguing that core Redux is absolutely essential for all apps, just that it's important to understand that some advanced users might prefer it. Just my 2 cents.
Finally, to add some context, we use Redux to power Makeswift. It's been indispensable for the wire protocol we use for postMessage communications as seen in our @makeswift/runtime package. We decided to go with vanilla Redux and redux-thunk, because it's extremely light weight and gives us exactly what we need.

@migueloller FWIW, skimming that @makeswift/runtime repo... it looks like you're using Immutable.js.   If bundle size is actually a concern, Immer is actually much smaller than Immutable.js (16K min vs 64K min), as well as easier to use overall.  So tbh I think you'd actually save quite a bit of bundle size by using RTK / Immer instead :)
Agreed that adding Immer is still a non-zero increase in bundle size.  But, given that Immer simplifies reducer code, eliminates accidental mutations (historically the historical single primary cause of Redux bugs), and makes reducer code easier to read... that is 100% a tradeoff I'm happy to make.  I wrote up that line of thinking in more detail in the "Writing Reducers with Immer" docs page:

https://redux-toolkit.js.org/usage/immer-reducers#why-immer-is-built-in

First, createSlice is biased towards a 1:1 relationship between reducers and actions while Redux has always been about a 1:n relationship between reducers and actions.

I both agree and disagree with this statement.
Yes, we've always encouraged multiple reducers responding to multiple actions.  In fact, I wrote that exact FAQ entry myself in 2016, and I specifically added an entry stating that you should "let multiple reducers handle the same action" when I wrote the Redux Style Guide page.
That said... I've seen thousands of Redux codebases, and in practice, at least 95% of all actions are only ever handled by a single reducer.
Given that, it makes sense to optimize for the most common use case: you write a reducer, and you get an action that triggers that reducer generated for free.
However, I explicitly wanted to make sure that createSlice could still do all the things you could do from writing a switch/case reducer by hand.  So, I intentionally added the extraReducers field to enable any createSlice-powered reducer to listen to actions that were defined outside of itself, whether they're coming from another slice, a standalone createAction call, a createAsyncThunk with its pending/fulfilled/rejected actions, or just a random action type string.
So yes, createSlice is aimed at the single most common way Redux users write reducers, but it's still flexible enough to handle 100% of the things you could do with a hand-written reducer.
I do understand that some users, like you, will continue to opt not to use RTK.  As I've said repeatedly: I'm not going to break your code. But I also frankly think you and others sharing that view are intentionally handicapping yourselves when it comes to using Redux, and discounting the benefits of RTK.  At that point, you've made your decision, and my focus has to be on the people who don't know enough about any of this yet and will benefit from us maintainers trying to point them in the correct direction for their long-term success.

The Immutable dependency is there to satisfy the peer dependency requirement of Slate. It's not used with Redux at all and is on its way out 😄. Also, because of code splitting, it's only included in places where the bundle size matters less.
Good to know that createSlice doesn't force 1:1 dependency between actions. For us, being able to handle an action in distinct reducers is super important because we dynamically load separate reducers that have a similar state type based on whether you're on the builder or a live page. The reducers respond differently to the actions.
I don't have anything against RTK and actually would love to try it out given the chance. I'm against deprecating createStore, though 😅. At the end of the day, it's not a huge deal. Like y'all have said, it's not going to break any code. It's more about the message it sends to people that do want to use createStore.

@migueloller FWIW you get all of the immer-related benefits even if you use createReducer instead of createSlice. My teams codebase does have lots of reducers that are more of a 1:n setup, with many actions being handled by multiple reducers. The combo of createAction and createReducer works perfectly for our use case.

Can you at least do it in a way, that doesn't feel like you're killing standalone redux?

Rename createStore to initializeStore or something sensible like that. No __unsafe, __legacy, __internal or any other suffix/prefix like that - Just a shiny new low level way to create store for everyone, including RTK.
Create new deprecated createStore with all the "Hey, maybe you shouldn't watch 5 years old tutorials" messages you need.
It would be nice if this was a major version change.

IMHO this way you'll get to get your message across without everyone who isn't using RTK on purpose feeling you just gave them big middle finger.
It's about perception.
Words have meaning. Deprecated means something will be sooner or later gone. Yet you stated multiple times you have no intention of removing it. So basically you'd be lying. That just feels wrong.
What also feels wrong is using deprecated stuff. And you'd be forcing us into it.
People don't want to have code full of deprecation warnings or unsafe/legacy flags for no good reason.
Redux is standalone independent library.
If you deprecate it's only entry point, it seems like you're going to kill it, since you no longer can normally use it.
If you deprecate something, everyone should stop using it, including RTK.
RTK isn't the only thing out there that is using redux. Why it should have extra privileges?

@zdhr "deprecated" does not mean "it will be removed", but "there is something better, please use that".
And even with every other solution you might be using that is not Redux Toolkit, if you are manually calling createStore in your application, Redux Toolkit's configureStore is the better solution - even if it is the only API from Redux Toolkit you will end up using.
configureStore:

automatically combines your reducers for you, no combineReducers call necessary (of course you can still do that if you e.g. want to set up a persisted rootReducer)
automatically calls applyMiddleware for you. You can either

pass in your own array of middlewares, or
it sets up a set of "default" middleware:

thunk
(in dev) the serializability middleware: this warns you if you accidentally pass non-serializable values into your store, as these are known to cause all kinds of bugs with the devtools and various ecosystem libraries, such as redux-persist
(in dev) the immutability middleware: this checks for accidental state mutation in reducers and between dispatches and warns you about those. That eliminates a whole class of errors, even if you still stick to hand-writing all your reducers with switch..case or use another library for reducer creation

you can configure all of these, or opt out of some of those default middlewares, and choose to combine them with your manual middlewares. It is totally possible to opt out of thunk, add saga and keep the serializability & immutability middlewares

it automatically sets up the devtools for you (of course you can disable them)
it allows you to add store enhancers without having to call compose
it allows you to pass in a preloadedState

All of that not with positional argument, but with a configuration object, which makes it very obvious for the reader on first sight what is actually going on there.
So, that single one fact alone is enough reason to deprecate one for the other. Even before we come to all the other reasons why we want to deprecate it - education being the most important one.

I want to reword what I said before. I'm not against deprecating createStore. Following the definition given multiple times here "deprecated means that there is something better, please use that", I'm ok with createStore being deprecated. The problem is that usually, the "better thing" that can be used is provided by the same package. Having to install a separate package feels like the original package can't stand by itself anymore if its entry point is deprecated and the "better thing" is elsewhere. This is why I think the argument to just bring RTK into Redux as a major is fine.
As for the suggestions to deprecate createStore and add another entry point called initializeStore or something like that, the idea would be to simply rename the function, keeping the same API. In this case, deprecation is being used as a social tool to promote a different way of doing something in a separate package, instead of as a tool to suggest a "better thing" or more specifically, "a better API". I think that's what's rubbing people the wrong way. Not changing the behavior of the Redux package but taking advantage of what deprecation does to nudge people into using a separate package. Not because the package is moving to a separate API, but because people are not using the toolkit built in too that makes it easier and less bug-prone.
Hopefully the better explains why it feels weird to deprecate createStore without bringing RTK into Redux or for some other reason other than "we want people to use RTK".

@migueloller we could of course just merge RTK into Redux, and honestly, at this point that would be the right thing to do if we were just having this whole discussion in a perfect world where there would not be two full sets of documentation maintained by essentially one person, two monorepos and 300k downloads of @reduxjs/toolkit a day that would essentially "hang in the air" afterwards.
We are trying to find a solution that we can realistically do (and humanpower/worktime is part of the question here) without interrupting users too much. And as it stands, it would probably both interrupt our RTK users more, just as our "plain Redux package users" if we were to suddenly merge one into the other. (also the ensuing discussion would probably even be more heated than this one)
It is probably just too late to do that at this point.
But if you want to get us to do it, please contribute to the discussion in https://github.com/reduxjs/redux/issues/3321 (and maybe offer a lot of your time, because we will need people doing that if we should really consider it)

@phryneas, I feel you. Another alternative is to deprecate redux and make @reduxjs/* packages the official ones. I just wanted to say that even though we're arguing here about deprecation and semantics, that the end of the day, y'all the maintainers are what make this possible and you're within your rights to make absolutely whatever changes you want. We wouldn't have RTK or redux, without you guys. Just wanted to make sure I said that. Really appreciate you guys.
So, what about merging redux into RTK? And then just stop upgrading redux after v8 and direct people to RTK? And perhaps the @reduxjs/core package can have createStore but by the time people move to @reduxjs/core they should already know and prefer to use RTK?

So, what about merging redux into RTK? And then just stop upgrading redux after v8 and direct people to RTK?

If this happens, where do the community of folks using redux go for help? Most likely to the same place they do now, to the Redux discord. They ask a question about the redux package, and they're directed to use @redux/core instead. In other words, the exact same flow as today.
I wonder if there would be a way to automate this process to reduce the burden on maintainers? We'd need to add a visual flag to the entry point of the redux package to catch users' eye. That visual flag would link to an article explaining the issue in-depth.
The @deprecated flag is the way to automate this process, which your suggestion wouldn't do.

@mattpocock, if redux itself is deprecated then that message can be added anywhere, createStore, NPM installs, etc.

@migueloller And what the others have said is that's an enormous job - moving the documentation around and refactoring the monorepo's. Adding a deprecation notice on createStore achieves the same thing with less effort.

I'm not suggesting a monorepo refactor, but simply deprecating all of redux instead of just createStore and then adding 1 new monorepo package @reduxjs/redux (or some other name like @reduxjs/core) that is where the new core lives. The old Redux docs can stay up with a big banner pointing to RTK and the deprecation notices of redux can point to RTK and this way there's no manual work to direct people there.
Anyhow, it's just an idea/suggestion. It doesn't have to be this way. I'm just trying to propose something that would achieve the maintainers' goals (deprecate core Redux so that people use RTK instead without having to do tons of work merging RTK into Redux or refactoring monorepos). I'm probably missing something since I'm not a maintainer, so I'll let the maintainers decide whether my suggestion/idea is useful or not.

@migueloller And what the others have said is that's an enormous job - moving the documentation around and refactoring the monorepo's. Adding a deprecation notice on createStore achieves the same thing with less effort - and is also reversible.

It doesn't quite achieve the same thing. In my mind, having the two separate is causing a lot of the confusion and I feel like combining the two (even just in a monorepo and not the same package) would allow the messaging to be a lot more clear. For example, I think one website instead of two would make it a lot easier to communicate how to use Redux today.
I'm not trying to say deprecating createStore isn't the right next step, I just feel like we'll always fall short unless we just do the bite the bullet and do the work of putting the two packages in the same monorepo and having the documentation centralized on one website with clear messaging.

Well, for what it's worth, @reduxjs/toolkit already re-exports everything from the redux package, so there will probably never be an installation that has both RTK and plain Redux in their package.json or imports from both.

Personally I think package renames, with a monorepo and single website, are the best way to go:
redux -> @reduxjs/core
@reduxjs/toolkit -> @reduxjs/redux
This would include a migration guide that explains that @reduxjs/redux is the main package and @reduxjs/core is just for advanced and legacy usage. The new combined website would consistently teach/use @reduxjs/redux throughout and @reduxjs/core documentation would be confined to its own section.
This is obviously more work, but in mind way it's the best way to message how the maintainers feel about the current status of how these packages should be taught and used.

On mobile and at a conference atm, but this is exactly the point I tried to make earlier.
Truly deprecating the entire Redux core package is an option. So is moving all of RTK into the core package. But it really would require converting everything to a monorepo as part of that. That is a massive amount of work that we simply do not judge the time or energy to do. Additionally, there's package whiplash. We already renamed RTK once. Our docs say to use it. I do not want to further disuse users by telling them to switch packages from RTK back to the combined "Redux" package.

And I don't understand why people are having a hard time accepting what I have repeatedly, clearly, and plainly stated about my motivations and intent here.

@zdhr

Words have meaning. Deprecated means something will be sooner or later gone. Yet you stated multiple times you have no intention of removing it. So basically you'd be lying. That just feels wrong.

No. I quoted the definition of "deprecated" from Wikipedia. Deprecation does not always imply "removal". You're ignoring the plain statement I have made repeatedly about what I intend to do here.

RTK isn't the only thing out there that is using redux. Why it should have extra privileges?

Because we are the maintainers.  We have spent thousands of hours writing documentation, responding to issues, answering question, fixing bugs, adding features.  We have seen how people use Redux and what problems they run into.  Therefore, it's our responsibility to make decisions about how the libraries should evolve, based on what we think is going to result in the best experience for our users and help them with the things they're trying to build.
It's really the story of the Little Red Hen. "If no one else is going to help me with this, I'll do it myself".
We welcome input from the community. That's why I even filed this as an issue in the first place and asked for feedback.  But at the end of the day it's our (unpaid! free time!) job to make the final decisions.

Done. I've added the @deprecated tag to createStore, verified that it visually shows up with a strikethrough and the updated description tag in hover tooltips, and added a new legacy_createStore that is an alias of the same function with a different docblock.
This is now live in Redux 4.2.0:
https://github.com/reduxjs/redux/releases/tag/v4.2.0

And I don't understand why people are having a hard time accepting what I have repeatedly, clearly, and plainly stated about my motivations, intent, and constraints here.

Yeah, deprecating createStore seems like the best option given your motivations, intent, and constraints. I just couldn't help talking about what the ideal seems like if the time constraint wasn't there. Congrats on getting this out.

Because we are the maintainers. We have spent thousands of hours writing documentation, responding to issues, answering question, fixing bugs, adding features. We have seen how people use Redux and what problems they run into.

It doesn't really sound like "maintaining" when the course of action is effectively deprecating the original library, and replacing with a new high-level API.  Surely there are people interested in actually maintaining the original, minimalistic Redux API, as conceived by Dan in 2015?  Which is ultimately what originally gained huge traction, spawned a large ecosystem, and has acted as a solid foundation for countless projects over many years.
While you may feel all those people are wrong, and the new approach is superior, couldn't this have been more easily shown by having the Redux Toolkit library's proposed "single standard approach" exist as its own library wrapping Redux, letting the numbers and adoption speak for themselves?  Why does it need to come at the expense of all those who are still happily using Redux's original low-level API?
Also, the presumption here that newcomers will pay attention to a deprecation notice, and "power users" can simply ignore it seems backwards to me.   Newcomers are more likely to just follow whatever they see in their chosen tutorial, and be happy to have something that runs.  Whereas experienced developers following best practices will be the ones who would not want to let a deprecated library call into their codebase.

@jamesisaac Have you read the thread above? Your various proposals have been answered. The library itself is not being removed or left unmaintained. How would you propose dealing with the issues faced by the current maintainers?

Surely there are people interested in actually maintaining the original, minimalistic Redux API, as conceived by Dan in 2015?

This feels deeply unfair to Mark and Lenz - they are the reason for Redux's continued relevance and prosperity.

@jamesisaac "maintainer" simply means "the people charge".  Riding on that word is a horrible take.
By the same logic, the React maintainers would not have been allowed to add ES6 classes, or hooks at a later time, because React with React.createClass was perfectly fine.

@mattpocock  Yes, I've read the whole thread.  Where did I say the library was being removed/unmaintained?  I said that a deprecation warning is hard for an experienced developer to ignore.  Regardless of what the docblock says, many would see it as a red flag to have any deprecated library calls in a codebase.

This feels deeply unfair to Mark and Lenz - they are the reason for Redux's continued relevance and prosperity.

How are you determining this?  If the problem is that too many people are still being introduced to Redux on the original API, doesn't that indicate the original unopinionated API is responsible for a lot of the relevance and prosperity?

@jamesisaac "maintainer" simply means "the people in charge".  Riding on that word is a horrible take.

Perhaps there is some relevance behind the word, particularly in a library which is used as a foundation in so many projects (2.1 million according to the stats GitHub pulls together).

By the same logic, the React maintainers would not have been allowed to add ES6 classes, or hooks at a later time, because React with React.createClass was perfectly fine and their whole job was to keep the first api someone had invented alive.

IMO this is not a reasonable comparison, as React.createClass purely existed as a workaround for lack of ES6 support..?  It would be more like React deprecating React.createElement (the low level API which is wrapped by higher-level APIs).  When in reality that is still perfectly usable and documented, and so are class components.  Hooks and functional components have grown in adoption organically, without the React team needing to introduce deprecations.

Also, you are free to fork Redux. Just don't assume you will have a lot of success - there are already 15000 redux-named packages on npm.

I'm just sharing my opinion on the redux NPM package, as that's what I've incorporated into many projects since 2015.  I'm aware that a fork is a viable solution, but obviously it's more disruptive than redux continuing to work with the same API it always has, without throwing out deprecation warnings.

Or just stay on the last version without the deprecation note. The Redux core is essentially done - those low-level apis are very unlikely to see any more changes, simply because after 7 years it is unlikely that anyone will come up with a newly found bug. (And remember, by your definition other than fixing bugs, there are no changes allowed.)

I mean that was pretty much my stance, that "Redux core is essentially done", barring the occasional bug fix or tweak in underlying implementation.  So I'm voicing the side of those who would find it useful to continue to use it that way without pinning to an old unmaintained version of the package.

I mean that was pretty much my stance, that "Redux core is essentially done", barring the occasional bug fix or tweak in underlying implementation. So I'm voicing the side of those who would find it useful to continue to use it that way without pinning to an old unmaintained version of the package.

The solution to that is, as per the release notes, the following change at one line in your application:
import { createStore } from 'redux';
import { legacy_createStore as createStore } from 'redux';

You don't need to pin anything at all.

How are you determining this? If the problem is that too many people are still being introduced to Redux on the original API, doesn't that indicate the original unopinionated API is responsible for a lot of the relevance and prosperity?

Following-up on that one:
The number of threads on twitter/reddit/hackernews saying "Redux is horrible" has decreased significantly while the number of threads saying "I like Redux again because of Redux Toolkit" has increased greatly. Fewer posts about "migrating away from the horrible boilerplate of Redux" are being written, or people are commenting under them that the author should really check out Redux Toolkit before daming the library.
In the last few years, a lot of people have voiced very loudly that they hate Redux. Those voices have gotten a lot less, both in frequency and volume. Without our efforts working on Redux Toolkit, Redux would likely not be a tool that newcomers would still learn because of the perceived notion that it is outdated and should not be used nowadays. It would probably be an irrelevant legacy tool, given one or two more years.

The only people giving that word any relevance are the intentions of the people calling themselves by that word. We could also just reference as ourselves as "team" from tomorrow on, it would not change how we work.

Ok, but then the point in my original comment still stands, that it would be helpful to let someone maintain (actual usage of the word) the low-level Redux API, while the "team" who wants to build out Redux Toolkit continues to do so.  They seem to be complementary libraries serving different use-cases.
Question on the new API - what are the solutions it provides for persistence (my main use-case for Redux)?  A quick search through your docs and all the examples seem to use the createStore API: https://redux.js.org/introduction/ecosystem#persistence

The solution to that is, as per the release notes, the following change at one line in your application:

IMO a legacy_ prefix is essentially the same as deprecating it.  Ultimately if someone is contracting me to build greenfield software for them, I would not import a library prefixing itself with legacy_ - the writing would clearly be on the wall that is not a future-proof solution, so it would be excluded for my options.

Question on the new API - what are the solutions it provides for persistence (my main use-case for Redux)? A quick search through your docs and all the examples seem to use the createStore API: redux.js.org/introduction/ecosystem#persistence

You can use redux-persist just as you did before. As redux-persist has been unmaintained for quite some time, it unfortunately still uses symbols as action types and you will get warnings about that with the serializability middleware enabled in development environments. The Redux Toolkit documentation describes how to exclude redux-persist from that warning in the Usage Guide until they put out a release fixing that (development on their side has begin again under a new maintainer).

IMO a legacy_ prefix is essentially the same as deprecating it. Ultimately if someone is contracting me to build greenfield software for them, I would not import a library prefixing itself with legacy_ - the writing would clearly be on the wall that is not a future-proof solution, so it would be excluded for my options.

Yes, if you start a new greenfield application using an api that has been superseeded for three years, requires four times the amount of code and is much more susceptible to bugs, that writing should probably be on all walls.

The number of threads on twitter/reddit/hackernews saying "Redux is horrible" has decreased significantly while the number of threads saying "I like Redux again because of Redux Toolkit" has increased greatly.

I do know the type of discussions you're talking about here, but IMO this is the vocal minority.  I imagine there are many developers who have been happily building on Redux for a long time, who don't spend their time getting involved in beginners' discussions about "is Redux is still worth learning or not?".
Personally I've revisited the Redux docs occasionally, read through the docs for RTK in the past, and decided it doesn't provide additional utility to me over base Redux.  If I realised the eventual plan was to make it the only viable option, maybe I would have been more vocal earlier about how base Redux has served me perfectly since day 1.

Yes, if you start a new greenfield application using an api that has been superseeded for three years, requires four times the amount of code and is much more susceptible to bugs, that writing should probably be on all walls.

Pairing it with a type system, I've had precisely zero of these problems.  I've had another look over the RTK docs and to me it is just additional APIs, re-solving problems that were already solved by following best practices or combining other complementary libraries (which has the benefits of those solutions being applicable to a wider domain than just reducers).  I do not see any way it would lead to reduction of verbosity or bugs for my usage patterns.
I completely see your point that for a newcomer, jumping into RTK may be preferable.  But my general point is that, Redux served its role extremely well as a low-level library, and it's nice having options available, with both solutions coexisting in parallel - which it doesn't seem there would be a barrier to.  If "Redux core is essentially done", and people are writing all over forums "I like Redux again because of Redux Toolkit", then it sounds like RTK would become the preferred solution organically, without needing to be at the expense of deprecating a low-level tool, which has no actual deficiency, has a wide ecosystem, and many are productively using.

sigh honestly:
If you yourself are educated enough that you decide for yourself not to follow the officially recommended best practices that the Redux team is propagating in the documentation and the Redux Style Guide because you know better, you surely are also educated enough that you can read and understand the deprecation warning, which contains the information that the api itself is not going away and make the conscious decision to ignore the deprecation warning in the same way as you are ignoring the style guide.
Ignoring one is the same writing on the wall as ignoring the other. It's your choice. Please stop complaining that you don't like one puzzle piece of that "writing on the wall". The decision has been made, the deprecation warning has been shipped, we are not going to take it back.

This conversation is going in circles. All the points have been made, the release is already shipped, and further arguing isn't going to change things.


Csharp armhf template

Adds c# armhf template
Description
Added a csharp-armhf template based on the previous csharp template. This is almost exactly similar to the previous csharp template, the only changes are in the template.yml language and adding fwatchdog-armhf instead of fwatchdog to the first docker builder.
Motivation and Context
Dotnet core added support for ARM32 see this link. This PR adds a template with arm support for csharp language.
How Has This Been Tested?
Tested on own raspberry pi running raspbian with openfaas deployed on docker swarm.
Testing steps:

Cloned the template to raspberry pi.
Created new function with faas-cli new --lang csharp-armhf temp
Build and deploy function with faas-cli build -f temp.yml && faas-cli deploy -f temp.yml
Invoke function from Openfaas ui.

This doesn't affect other templates.
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I've read the CONTRIBUTION guide
[x] I have signed-off my commits with git commit -s
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

Hi @zeerorg
There was a report on Slack of this template not working and failing to load the function.
Could you look into it please?
Alex

When I updated to 2.2 I got this error:
curl -d test http://<IP_ADDRESS>:8080/function/ctest
exit status 136
Failed to load ?B?, error: libunwind.so.8: cannot open shared object file: No such file or directory
Failed to bind to CoreCLR at '/home/app/libcoreclr.so'

FROM alpine:3.8 as watchdog

RUN apk --no-cache add curl \
    && echo "Pulling watchdog binary from Github." \
    && curl -sSL https://github.com/openfaas/faas/releases/download/0.13.0/fwatchdog-armhf > /usr/bin/fwatchdog \
    && chmod +x /usr/bin/fwatchdog \
    && cp /usr/bin/fwatchdog /home/app \
    && apk del curl --no-cache

FROM mcr.microsoft.com/dotnet/core/sdk:2.2.203-stretch-arm32v7 as builder

# Supress collection of data.
ENV DOTNET_CLI_TELEMETRY_OPTOUT 1

# Optimize for Docker builder caching by adding projects first.

RUN mkdir -p /home/app/src/function
WORKDIR /home/app/src/function
COPY ./function/Function.csproj  .

WORKDIR /home/app/src/
COPY ./root.csproj  .
RUN dotnet restore ./root.csproj

COPY .  .

RUN dotnet publish -c release -o published -r linux-arm

FROM mcr.microsoft.com/dotnet/core/runtime:2.2.4-stretch-slim-arm32v7

COPY --from=watchdog /usr/bin/fwatchdog  /usr/bin/

# Create a non-root user
RUN addgroup --system app \
    && adduser --system --ingroup app app

WORKDIR /home/app/
COPY --from=builder /home/app/src/published .
RUN chown app:app -R /home/app

USER app

ENV fprocess="dotnet ./root.dll"
EXPOSE 8080

HEALTHCHECK --interval=3s CMD [ -e /tmp/.lock ] || exit 1

CMD ["fwatchdog"]


Create a training spinoff checklist

We need a check list to keep us organized for when we kick off MDSA trainings
Things we always need to do are...

Create a github repo and team
Collect all github usernames
Work with IT OPs to get all GitHub users added to our organization
Create a dbt account (this is done by dbt)
Create a snowflake account
Edits all training materials
Check what we committed to adding or improving

I'll turn this into a doc! For now if I am missing something feel free to comment it to the thread

This can be reused for future MDSA projects @jkarpen


feat(llgo/c/spdlog): Added a C++ logging library : spdlog

[ ] readme.md

Please send pr to https://github.com/goplus/llgoexamples


Fix issue #1343

do check and let me know if everything is correct

Hi @slayer321,
what would actually be needed is to change the name of the resulting binaries. The assignment of the binary names happens in https://github.com/SymbiFlow/prjxray/blob/master/tools/CMakeLists.txt.
Take the following as an example: https://github.com/SymbiFlow/prjxray/blob/80726cb73ba5c156549d98a2055f1ee3eff94530/tools/CMakeLists.txt#L7.
To change bittool to be xc7bittool you should modfiy that line to be:
add_executable(xc7bittool bittool.cc)
target_link_libraries(xc7bittool libprjxray gflags absl::strings absl::span)

Moreover, these tools are used in different parts in prjxray, so the change in the tools names need to be addressed also where the tools are used.

ok, I understood that I just need to change the name here in this file . and what about the changes that I did . that was not needed right?


"webadmin.lua file is already provided by package *luci-base"

I just Installed(Fresh) OpenWrt 19.07.2.
opkg update && opkg install luci-app-ddns (or anything start with luci-app-).

Collected errors:

check_data_file_clashes: Package luci-compat wants to install file /usr/lib/lua/luci/tools/webadmin.lua
But that file is already provided by package  * luci-base
opkg_install_cmd: Cannot install package luci-app-ddns.

I temporary resolved this issue. Using --force-overwrite option to opkg, problem solved.

opkg upgrade luci-base


Slides with variable width

I have the slides of variable width, and it takes the width of the maximum slide as the width and computes the slides per view according to that which is quite ugly. Is there a way to fix this, such that each slide take the width of the child inside it?

set slidesPerView: 'auto'


db:automigrate fails dm 1.3.0 - beta and mysql

Hello,
I'm running a rails 3.2.1 project with dm-* 1.3.0.beta and using mysql database. When I run db:automigrate it fails:
Tried in a Windows and Linux environment.
Can't create table 'mytable.#sql-618_4d' (errno: 150)
C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-do-adapter-d295d77f3e4b/lib/dm-do-adapter/adapter.rb:63:in execute_non_query' C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-do-adapter-d295d77f3e4b/lib/dm-do-adapter/adapter.rb:63:in block in execute'
C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-do-adapter-d295d77f3e4b/lib/dm-do-adapter/adapter.rb:276:in with_connection' C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-do-adapter-d295d77f3e4b/lib/dm-do-adapter/adapter.rb:61:in execute'
C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-constraints-67cfad8018ed/lib/data_mapper/constraints/adapters/do_adapter.rb:71:in create_relationship_ constraint' C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-constraints-67cfad8018ed/lib/data_mapper/constraints/migrations/relationship.rb:19:in auto_migrate_con
straints_up'
C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-constraints-67cfad8018ed/lib/data_mapper/constraints/migrations/model.rb:16:in block in auto_migrate_c onstraints_up' C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-core-3aee0ec24233/lib/dm-core/support/subject_set.rb:210:in block in each'
C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-core-3aee0ec24233/lib/dm-core/support/ordered_set.rb:319:in block in each' C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-core-3aee0ec24233/lib/dm-core/support/ordered_set.rb:319:in each'
C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-core-3aee0ec24233/lib/dm-core/support/ordered_set.rb:319:in each' C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-core-3aee0ec24233/lib/dm-core/support/subject_set.rb:210:in each'
C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/dm-constraints-67cfad8018ed/lib/data_mapper/constraints/migrations/model.rb:15:in `auto_migrate_constraint
Regards,
Carlos

i remember one more thing: if you declare your FK properties (integers) explicitly (i.e. not using belongs_to but property), you need to add a :min => 0 option to the integer property. Otherwise, mysql cannot match the types. Again, this might not solve your specific problem, but it's something to be aware of. Unfortunately I don't have time now to investigate further.

@carlosacp What version of MySQL are you using? Are you able to create a single file with an example of something that fails for you? Then we can run it here and see if it still fails, and start debugging it. Right now it's difficult to determine if it's something local to your system, or an actual bug in the software, so having a reproduction would be a great first step.

I'm going to close this, as it seems to be resolved on dm-core master.


New Calculator

Enter calculator name -
Laplace Transform Calculator
Describe calculator functionality -
Computes the Laplace transform of a given function.
Under which category you wish to place it -

[ ] Computer Science
[ ] Mathematics
[ ] Physics
[ ] Chemistry
[ ] Biology
[ ] Art
[ ] Finance
[ ] Scientific
[ ] Health
[ ] Sports
[x] Let project owner decide
[ ] Suggest a new category - (Answer here)

@SarthakKeshari Kindly assign me this issue

Hey @Saket2701,
Glad to see your eagerness for contributing 🤩.  This issue has already been addressed.
Hope to see you come up with more innovative issues.
Happy contributing!! 🎉


Style debug page

Ensure styling for the debug page from the old theme is still there in the base theme.
Added old theme as components in a dedicated folder to avoid duplication.

I noticed the foldername: oldNotConverted does not adhere to the folder naming convention: old-not-converted is the correct way.

waves his fixup wand
This spelling was always there 😇 (nothing like a bit of git magic to make you feel like a wizard)

I noticed the foldername: oldNotConverted does not adhere to the folder naming convention: old-not-converted is the correct way.

waves his fixup wand
This spelling was always there 😇 (nothing like a bit of git magic to make you feel like a wizard)

Please don't mention the src folder structure. Which is infested with CamelCased folder names. That however is PSR-4 spicing and therefor allowed :rabbit2:

Please don't mention the src folder structure. Which is infested with CamelCased folder names. That however is PSR-4 spicing and therefor allowed :rabbit2:

You got it! Thanks for your patience.

And yours!  What a nailbiter in the end 🚵♂

You got it! Thanks for your patience.

And yours!  What a nailbiter in the end 🚵♂


Update?

Will RN-DND still be maintained?

any plan to release a new version???

I guess v2.3.0 answered your question, you can close this issue.


Not ripping m.imgur.com galleries

Example: http://m.imgur.com/1ulB5Rr,jUnwFcS,anGsFuP,7PHezez,qv00CvM,IDMOWBs,RaZHrtm linked from profile https://www.reddit.com/user/Xx88xXy/submitted/
It will only rip the first picture and ignore the rest, despite them showing up on imgur a album.

Thanks for the example URL!
I think I fixed this in the latest version.


Nil pointer panic on eval with -O

What version of CUE are you using (cue version)?

$ cue version
cue version 0.3.0-beta.2 darwin/amd64

Does this issue reproduce with the latest release?
Yep.
What did you do?
cue eval -iO uPlot.cue - original file is in this gist.

What did you expect to see?
Well, not a panic 😉 The appropriate eval'd output.
 :) The optional output with eval is indeed a bit shoddy. No excuse for a panic, though, of course.
Background: eval is a bit an unprincipled output. cue def prints schemas and cue export --out cue prints concrete CUE output. eval was originally intended as a sort of in-between, optimized for debugging. The way CUE works, it makes it hard to define what an optional field means in this in-between state. We plan to clean up the semantics and streamline the output modes. Part of that is already done, but eval+optionals hasn't gotten much love. But again, a crash is not okay.

Hey Sam, good to see you here. :) The optional output with eval is indeed a bit shoddy. No excuse for a panic, though, of course.
Background: eval is a bit an unprincipled output. cue def prints schemas and cue export --out cue prints concrete CUE output. eval was originally intended as a sort of in-between, optimized for debugging. The way CUE works, it makes it hard to define what an optional field means in this in-between state. We plan to clean up the semantics and streamline the output modes. Part of that is already done, but eval+optionals hasn't gotten much love. But again, a crash is not okay.

Glad to be here! i'm quite excited about what you appear to be aiming for with CUE. If i can figure out how to conform it to our needs, it's plausible that we could start using it for some pretty key in Grafana. Fortunately, the baby steps we need for now don't look terribly challenging :wink:
Totally understood on the intermediate form. Perhaps i'm overdrawing on my own experience areas and assuming they're analogous, but i can imagine attempting to define relations over optional fields could get hairy due to negation ambiguities/3VL-type problems.
No worries on the panic! The notion that, as you say, there exists a relative ordering of concreteness between def, eval and export is super useful, and really lights up something in my mind. As i've been spelunking CUE, i've formed the notion that degrees of concreteness are a foundational piece of both how CUE works, and how one ought to think about it in order to use it effectively. With that in mind, here's a quick attempt at making my lack-of-curse-of-knowledge hopefully useful for you.
i organically found my way to this particular use of cue eval just by relatively blindly following the tutorial, where cue eval seemed to be what i was seeing most of the time. As i looked through cue help, it wasn't actually clear to me what i ought to use in order to illustrate my desired goal to some other folks - which, basically, is turning most of the declarations in a file like this into something we can generate from CUE files. (i'm now prototyping a very simple generator to do exactly that.) I added the -O when i discovered that the optional fields - clearly, almost everything there - were omitted. (i then subsequently ran into #665 when experimenting with attributes in this same file, with the intent of feeding them to my custom generator.)
Again, this relative concreteness thing seems super important. Idk how feasible or valuable this is, but i'll throw it out there: the tutorials might be an opportunity to reflect that importance. While it wouldn't necessarily work well for all of the tutorial steps, i'm imagining that, rather than showing just one output (which seems a tad random as to whether eval, or export are used?), it could show all three. i'm picturing tabs on the output box akin to when code samples are given for a particular task in various languages, tabbed by language in the same box.

Glad to be here! i'm quite excited about what you appear to be aiming for with CUE. If i can figure out how to conform it to our needs, it's plausible that we could start using it for some pretty key in Grafana. Fortunately, the baby steps we need for now don't look terribly challenging :wink:
Totally understood on the intermediate form. Perhaps i'm overdrawing on my own experience areas and assuming they're analogous, but i can imagine attempting to define relations over optional fields could get hairy due to negation ambiguities/3VL-type problems.
No worries on the panic! The notion that, as you say, there exists a relative ordering of concreteness between def, eval and export is super useful, and really lights up something in my mind. As i've been spelunking CUE, i've formed the notion that degrees of concreteness are a foundational piece of both how CUE works, and how one ought to think about it in order to use it effectively. With that in mind, here's a quick attempt at making my lack-of-curse-of-knowledge hopefully useful for you.
i organically found my way to this particular use of cue eval just by relatively blindly following the tutorial, where cue eval seemed to be what i was seeing most of the time. As i looked through cue help, it wasn't actually clear to me what i ought to use in order to illustrate my desired goal to some other folks - which, basically, is turning most of the declarations in a file like this into something we can generate from CUE files. (i'm now prototyping a very simple generator to do exactly that.) I added the -O when i discovered that the optional fields - clearly, almost everything there - were omitted. (i then subsequently ran into #665 when experimenting with attributes in this same file, with the intent of feeding them to my custom generator.)
Again, this relative concreteness thing seems super important. Idk how feasible or valuable this is, but i'll throw it out there: the tutorials might be an opportunity to reflect that importance. While it wouldn't necessarily work well for all of the tutorial steps, i'm imagining that, rather than showing just one output (which seems a tad random as to whether eval, or export are used?), it could show all three. i'm picturing tabs on the output box akin to when code samples are given for a particular task in various languages, tabbed by language in the same box.

This issue has been migrated to https://github.com/cue-lang/cue/issues/662.
For more details about CUE's migration to a new home, please see https://github.com/cue-lang/cue/issues/1078.