Skip to content

Integrate js-lint and removing old linting elements #22

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
May 8, 2025
Merged

Integrate js-lint and removing old linting elements #22

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9190cd5
feat: added @matrixai/lint and removed old linting elements, ran lint…
CDeltakai Apr 22, 2025
4c57d51
fix: updated js-lint to 0.2.1 to fix variadic options issue
CDeltakai May 8, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
177 changes: 0 additions & 177 deletions .eslintrc
View file
Open in desktop

This file was deleted.

26 changes: 13 additions & 13 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,17 +4,17 @@ This library provides the ability to cancel asynchronous tasks. Cancelling async

> The following are some architectural observations provided by **Dean Tribble** on the [es-discuss mailing list](https://mail.mozilla.org/pipermail/es-discuss/2015-March/041887.html):
>
> *Cancel requests, not results*
> _Cancel requests, not results_
>
> Promises are like object references for async; any particular promise might
> be returned or passed to more than one client. Usually, programmers would
> be surprised if a returned or passed in reference just got ripped out from
> under them *by another client*. this is especially obvious when considering
> under them _by another client_. this is especially obvious when considering
> a library that gets a promise passed into it. Using "cancel" on the promise
> is like having delete on object references; it's dangerous to use, and
> unreliable to have used by others.
>
> *Cancellation is heterogeneous*
> _Cancellation is heterogeneous_
>
> It can be misleading to think about canceling a single activity. In most
> systems, when cancellation happens, many unrelated tasks may need to be
Expand All @@ -23,14 +23,14 @@ This library provides the ability to cancel asynchronous tasks. Cancelling async
> happen?
>
> - the async fetch of more query results should be terminated and the
> connection closed
> connection closed
> - background computation to process the remote results into renderable
> form should be stopped
> form should be stopped
> - rendering of not-yet rendered content should be stopped. this might
> include retrieval of secondary content for the items no longer of interest
> (e.g., album covers for the songs found by a complicated content search)
> include retrieval of secondary content for the items no longer of interest
> (e.g., album covers for the songs found by a complicated content search)
> - the animation of "loading more" should be stopped, and should be
> replaced with "user cancelled"
> replaced with "user cancelled"
> - etc.
>
> Some of these are different levels of abstraction, and for any non-trivial
Expand All @@ -41,7 +41,7 @@ This library provides the ability to cancel asynchronous tasks. Cancelling async
> get passed the one that would be cancelled if the user hits stop and the
> right thing happens.
>
> *Cancellation should be smart*
> _Cancellation should be smart_
>
> Libraries can and should be smart about how they cancel. In the case of an
> async query, once the result of a query from the server has come back, it
Expand All @@ -54,7 +54,7 @@ This library provides the ability to cancel asynchronous tasks. Cancelling async
> worker complete (so that you can reuse it) rather than abruptly terminate
> it (requiring discarding of the running worker and cached state).
>
> *Cancellation is a race*
> _Cancellation is a race_
>
> In an async system, new activities may be getting continuously scheduled by
> asks that are themselves scheduled but not currently running. The act of
Expand All @@ -70,7 +70,7 @@ This library provides the ability to cancel asynchronous tasks. Cancelling async
> system), but that schedules work that will be cancelled (parse the
> publication of an update to the now-cancelled query).
>
> *Cancellation is "don't care"*
> _Cancellation is "don't care"_
>
> Because smart cancellation sometimes doesn't stop anything and in an async
> environment, cancellation is racing with progress, it is at most "best
Expand All @@ -82,7 +82,7 @@ This library provides the ability to cancel asynchronous tasks. Cancelling async
> and transactions. It was amazing how much simpler cancellation logic
> becomes when it's "don't care".
>
> *Cancellation requires separation of concerns*
> _Cancellation requires separation of concerns_
>
> In the pattern where more than one thing gets cancelled, the source of the
> cancellation is rarely one of the things to be cancelled. It would be a
Expand All @@ -92,7 +92,7 @@ This library provides the ability to cancel asynchronous tasks. Cancelling async
> cancellation token and cancellation source mirrors that separation between
> a promise and it's resolver.
>
> *Cancellation recovery is transient*
> _Cancellation recovery is transient_
>
> As a task progresses, the cleanup action may change. In the example above,
> if the data table requests more results upon scrolling, it's cancellation
Expand Down
Loading