Skip to content
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.

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

Typescript should follow semantic versioning #14116

Closed
jbgraug opened this issue Feb 16, 2017 · 26 comments

Comments

@jbgraug
Copy link

commented Feb 16, 2017

I guess this can be considered as a bug as it is breaking my apps.
If version 2.1.0 has breaking changes, why don't set it to 3.0.0? Semantic versioning, right?
Typescript lives and has important role in the nodejs ecosystem, therefore should follow some basic rules.
We can not use the npm's semver features to block only major changes.

TypeScript Version: 2.1.1 / nightly (2.2.0-dev.201xxxxx)

2.1.0
Code

// A *self-contained* demonstration of the problem follows...
No need

Expected behavior:
Follow semantic versioning rules
Actual behavior:
Just follows marketing versioning rules
can be related to #6520 created a year ago and closed without being solved

@mhegazy

This comment has been minimized.

Copy link

commented Feb 16, 2017

TypeScript never claimed to follow semantic versioning, in the sense that breaking changes imply major versions.

TypeScript, however, promises no breaking changes after a stable release. so no breaking changes between 2.1.5 and 2.1.6, 2.1.*.

My recommendation is fix your version of typescript to major.minor instead of just major. e.g. ^2.1 and not ^2

@jbgraug

This comment has been minimized.

Copy link
Author

commented Feb 17, 2017

Thanks for the early response @mhegazy .
As you mentioned, blocking the versions is easy to fix in my projects (I was being a bit ironic.).
However, as a developer i don't feel comfortable having to memorise a different set of rules for each package as the number of packages used grows very quickly.
I guess having typescript follow semantic versioning would be a nice to have feature.

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

commented Feb 17, 2017

The trade-off for getting millions of dollars of engineering investment in the TypeScript project is that marketing gets to control version numbers to a certain extent.

It's not really an unalloyed good anyway. If we followed semver rules exactly, literally every single release would be a major version bump. Any time we produced the wrong type or emitted the wrong code or failed to issue a correct error, that's a breaking change, and we fix dozens of bugs like that in every release. The middle digit just isn't useful for TypeScript in a strict semver interpretation.

@niieani

This comment has been minimized.

Copy link

commented Feb 19, 2017

NPM should simply allow for descriptive marketing versions as a forth group. Then we'd have the best of both worlds, i.e.

       marketing
           ∨
TypeScript 2.34.2.1 
             ∧∧ ∧ ∧
          major ∧ patch
                ∧
              minor

You would simply skip the marketing version while installing, i.e. npm install typescript@^34 since it would hold no semantic meaning, i.e. bumping marketing wouldn't reset the major counter.

@BenSayers

This comment has been minimized.

Copy link

commented Apr 7, 2017

I'm concerned that not following semver is creating unnecessary friction for TypeScript consumers who are opted in to having their builds broken whenever TypeScript releases a minor version as npm locks down to only major versions by default. The Microsoft Edge team has figured out how to do their marketing despite bumping the major version a few times a month (currently up to v38), I think TypeScript should give serious consideration to doing the same for the good of its consumers.

@aluanhaddad

This comment has been minimized.

Copy link
Contributor

commented Apr 7, 2017

Personally, I think it is a good idea to always specify exact versions of critical stack components such as compilers, loaders, bundlers, and of course frameworks.

There are not that many of these tools in a single project and they do not tend to release more than once a week or so. This makes explicitly upgrading a relatively straightforward process.

Also, reading the changelogs for updates to such key dependencies is almost certainly something that one should be doing.

That said, I think it's fine to version more liberally. Each project is different in this regard.

The trade-off for getting millions of dollars of engineering investment in the TypeScript project is that marketing gets to control version numbers to a certain extent.

That is a trade well worth making.

Furthermore, TypeScript is by no means the only project that does this.

I think any project that is high profile enough is likely subject to this, at least to some extent.

Even if it is not the marketing department, it may be the maintainers' own self-consciousness that leads to such versioning.

Any time we produced the wrong type or emitted the wrong code or failed to issue a correct error, that's a breaking change, and we fix dozens of bugs like that in every release.

TypeScript really releases at a blisteringly unprecedented pace for a programming language so I think this is somewhat inevitable. I also think it's common across almost all software. Minor versions of most software contain breaking changes, but they often go unnoticed. The more high-profile the project, the more users that has, the more likely it is that this will be noticed.

The TypeScript team do an incredible job and they ship a wonderfully high quality product.

@gcnew

This comment has been minimized.

Copy link
Contributor

commented Apr 7, 2017

I can't agree with @aluanhaddad more. Personally, I think using language version 81 and browser version 127 is terrible. It looks ugly and these high numbers quickly become meaningless. In the browser case that's the intention - forcing consumers to update to the latest version. However, for a language it's out of place and makes following new features and important changes extremely hard. Every version, no matter how big or small, looks the same way as every other. Flow has fallen in that trap and it doesn't seem to reap many benefits out of it.

For TypeScript, if you still want automatic updates without worrying too much, just lock the minor version in and everything will fall into place.

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

commented Apr 7, 2017

I mean, even semver's own definition of "breaking change" is arguably wrong. Minor updates can add new functionality under new properties, and new properties can break existing codepaths because JS is full of do-x-if-y-property-is-present patterns. Fixing a performance bug, which would in theory be a bugfix version update, could cause two async operations which previously always resolved in one order to instead always resolve in another order.

It is simply not the case that you can safely upgrade code, with semver as used today by normal package maintainers, from 34.1 of some library to 34.9 and be guaranteed that your program will still behave the same way.

What semver means in practice is that the major version bump is "You will probably need to update your code in a lot of places", and the minor version bump is "You should always be OK for the most part". TypeScript never makes updates of the first kind. We only make compat-breaking changes where we believe you should always be OK modulo a small number of fixes we think you'll be happy making (because we found new bugs).

We're not going to take a major version bump because there was a bug in the compiler where it failed to identify early errors, even though that's technically a breaking change - we think you should be "along for the ride" on that one if you didn't shrinkwrap. That's how semver is used in practice by everyone anyway.

@mhegazy mhegazy closed this Apr 19, 2017
@eddieajau

This comment has been minimized.

Copy link

commented Jun 15, 2017

Can we at least get a section on "TypeScript and Semver" added to the docs? The fundamental problem is that npm install --save typescript will add `"typescript":"^2.4.0" by default. Consumers need to be aware that this is dangerous and you need to change it to "~2.4.0" (tilde, not carat). I'm happy to do the PR if you can advise on where you want such information.

But for what it's worth:

"You will probably need to update your code in a lot of places" ... TypeScript never makes updates of the first kind.

The Promise changes in 2.4 is resulting in lots of little changes all over the place. I'm not saying I don't agree with the changes, but they are there nonetheless. I've been caught only because I've [wrongly] assumed that TypeScript was following Semver.

@daprahamian

This comment has been minimized.

Copy link

commented Jun 21, 2017

I'd like to add a related question: should type definition files be compatible across all of 2.x.x? Can someone compile their library in 2.2, and have it work when someone pulls it in and compiles with 2.1?

@DynConcepts

This comment has been minimized.

Copy link

commented Jul 10, 2017

I too would prefer SemVer, and yes I know the majority of publishers are not "doing it right"...But lets look at an earlier comment:

"If we followed semver rules exactly, literally every single release would be a major version bump. Any time we produced the wrong type or emitted the wrong code or failed to issue a correct error, that's a breaking change, and we fix dozens of bugs like that in every release. "

Writing quality software is hard and requires investment. The above can be mitigated with improved testing and documentation.

Remember the Agile principle: "the art of maximizing the amount of work not done--is essential. ". This should not mean the amount of work done by a team to get something out the door. Rather it should be a global optimization to minimize the work required by all stakeholders globally and across type - the TOTAL work.

@daprahamian

This comment has been minimized.

Copy link

commented Jul 11, 2017

If it is not possible to follow semver, could we come up with some sort of way to enable backwards compatibility / legacy behavior in our code? I am currently dealing with two major issues that I view as breaking changes:

Consuming a library where the .d.ts files are compiled in TS version higher than my project.

Example: Using TS 2.0, consuming a project that exports an interface with a member that is of type object.

A few ideas on how to fix this:

  • Allow TypeScript to compile to a previous version's output.
  • Allow TypeScript to compile to multiple versions of types output, and then include a root file that routes the consuming compiler to the right definition using some sort of markup (comments, conditional compilation, etc.)

Consuming a library where the .d.ts files are compiled in a TS version lower than my project.

Some examples include:

All of these issues stem from stricter type checking introduced in a later version of TS. This could probably be mitigated by doing the following:

  1. Having .d.ts files contian the compiler version via comments
  2. Having the compiler check the imported code's compiler version, and only apply new/stricter rules if they existed in the compiled version.
@jsamr

This comment has been minimized.

Copy link

commented Nov 23, 2017

And what about a new package.json property : "breaking" which values can be "MAJOR" (default), "MINOR" ?
See npm/npm#19231

@FranklinYu

This comment has been minimized.

Copy link

commented Jun 8, 2018

Fixing a performance bug, which would in theory be a bugfix version update, could cause two async operations which previously always resolved in one order to instead always resolve in another order.

If the resolution order is documented, then indeed it is breaking change and should bump major version; otherwise it is implementation details and user is responsible for depending on this.

@calidion

This comment has been minimized.

Copy link

commented Feb 6, 2019

@mhegazy You have my full support. Semver is evil. And should be rejected everywhere. Typescript is a very good example.

@eps1lon

This comment has been minimized.

Copy link

commented Feb 6, 2019

Fixing a performance bug, which would in theory be a bugfix version update, could cause two async operations which previously always resolved in one order to instead always resolve in another order.

This is one of the go to arguments against SemVer and it's a classic strawman. The very first point of the SemVer spec invalidates the argument here that "semvers own definition is wrong. here's why:"

  1. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive.

If your public API declared that two operations resolve in a given order then, yes, a performance fix is probably a breaking change. However I don't know any library that declares two public functions and declares that one is always fast than the other.

I agree if you don't have a public API then the SemVer is meaningless. However most of the issues with SemVer are a result of a problematic public API. Also https://xkcd.com/1172/: Just because a change breaks a workflow does not mean it is a SemVer breaking change if the public API never documented that workflow.

@calidion

This comment has been minimized.

Copy link

commented Feb 7, 2019

Even with public apis, semver should never be applied.
Version update is a way to note software changes, not software compatibility.
Main versions for architectural or big updates. Minor versions for small changes and new feature additions. Patch versions for bug fixes. Either one can break compatibility.

Semver is stupid focusing on compatibility, which is nothing to do with versions.

Compatibility should be maintained by developers and test cases.

npm is stupid in auto version updates which cause security issues and instability. The false assumption is originated from the idea semver bearing where versions should to be compatible within main version.

@calidion

This comment has been minimized.

Copy link

commented Feb 7, 2019

Another principal should be never update until updates are fully tested.

@jsamr

This comment has been minimized.

Copy link

commented Feb 7, 2019

Compatibility should be maintained by developers and test cases.

So developers should test all the API surface they consume ? That is a big field.
In my opinion, they should test all the undocumented assumptions they are making on third party APIs. And of course, unexposed callpoints (classes and methods) they might use or inherit.

Fixing a performance bug, which would in theory be a bugfix version update, could cause two async operations which previously always resolved in one order to instead always resolve in another order.

If you are assuming the order in which those async tasks resolve, you are Programming by Coincidence (The Pragmatic Programmer, Ch. 6). This is a major flaw in your development process.
Breaking in SemVer means breaking the contract, not your program. If your program doesn't fulfil its contract with an API, minor changes might well break it (Design by Contract).

@calidion

This comment has been minimized.

Copy link

commented Feb 7, 2019

@jsamr No one can do that.

No one can 100% predict the process of the software development.

Software development is more of a way of exploring than a process of promise keeping.
It is good to bear Design by Contract in mind and not to Programming by Coincidence.
But the real life is not functioning that way.
You even can't promise that your code is 100% correct.
Why you dear to say your updates are 100% compatible when you released a version?

We should respect Design by Contract and Pragmatic Programmers.
And we should also know that we are human beings, who make mistakes and break promises.
It is the fact and reality.
We lives in reality not in illusion or theory.

The promise semver wants to keep breaks everyday and you still not wake up.
Why?

Do you really know the difference between angular 2, 3, 4 and 5?
Do you really care?
Why you care about the compatibility ? or you are simply driven by those people who propagating semver?
Why should update be compatible while you even don't write test cases?
Why should you update when no test is made ? Is that a pragmatic way?

Never lie to yourself.

To keep compatibility is a very good practice, but to assume compatibility is a very stupid thought.

For major, minor, patch, all versions should try to keep compatibility.
For developers, should never trust compatibility.

@jsamr

This comment has been minimized.

Copy link

commented Feb 7, 2019

@calidion I think we are misunderstanding each other.

I have never claimed that I can promise code is 100% correct. However, a library author can aim at testing all the features exposed to consumers.

However, it doesn't mean there is 0 chance a minor upgrade will break the contract entitled by its authors.
Semantic versioning is, from a producer perspective, about expressing the contract and its retro-compatibility. Patches are here to correct a mismatch between the contract and its implementation.

It's not, from a consumer perspective, about neutralizing the risk of upgrading. I agree with you about testing upgrades, of course. Even better : put those tests in a pull request to library authors. If a test fails, they'll fix it and upgrade their patch version.

Your argument is similar to refuting the utility of Laws because we can't promise it will be applied fairly to everybody. Do you have in mind a better system to address, from a producer perspective, the contract and retro-compatibility issues in library development? I don't, and that is why I find compliance with semantic versioning great.

The flaw in npm use of semantic versioning has been addressed with lockfiles.

@DynConcepts

This comment has been minimized.

Copy link

commented Feb 7, 2019

If SemVer is to be of value only to the producer [i.e. the consumer can not base their actions reliability upon it] then what is the value of it even being exposed to the consumer????

Yes, I agree it is about contracts, but this leads to the discussion of what exactly is a contract that provides the value necessary to truly be useful to the consumer.... In my experience there are multiple orders of magnitude between what is typically produced as a contract [by the publisher] and what is needed by the consumer to determine the impact on their usage.

@calidion

This comment has been minimized.

Copy link

commented Feb 8, 2019

@jsamr

Software won't get matured by merely contracts.
It is a much more complicated way.

Like humans constantly violating laws, software development will surely break contracts.

So it is stupid to believe in contracts.

There are police stations and courts for law violations.
There are no such things for software development and publishing.

No one wants to breaks compatibility, but it is inevitable even when semver is applied.

It's in fact not about contracts, It is about evolution which cannot be predicted precisely.

Another wrong believe is that updated should always be executed after software updates.

Nodejs has a service called green keeper which strengthens that wrong believe.

Software quality is nothing to do with updates, newer updates maybe worse and mass things up.

so updates should be applied when they are tested extensively not because they are newer.

programmers should be selective to one stable version.

For example Ubuntu 16.04 is more stable than 17.04, 16.10, and even 18.04.

Win 7 is more popular than win 8, win 10.

There are in fact no contracts, there are just releases.

@jsamr

This comment has been minimized.

Copy link

commented Feb 8, 2019

@calidion It would be appreciable and civilized if you stopped calling the other's point of view — or the point of view you think they hold — "stupid". Just be decent and follow the community's rules. Even worse, you don't seem to try to understand the other side point of view, and rush to your own conclusions.

@DynConcepts

[If] the consumer cannot base their actions reliability upon [semantic versioning], then what is the value of it even being exposed to the consumer?

Very easy. Just imagine a version signature which has majors only, which would be equivalent to a standardless version signature (i.e., not semantic).

You need to upgrade a library from version 234 503 to 244 503 because this last version gives compatibility to a set of target platforms you need to integrate.

But you have no idea of the intended breaking changes by just looking at the signature. So you have to read the changelog from 234 503 to 244 503, have fun!

Quoting from the original specification:

Without compliance to some sort of formal specification, version numbers are essentially useless for dependency management. By giving a name and clear definition to the above ideas, it becomes easy to communicate your intentions to the users of your software.

Semantic versioning is about communicating, nothing more.

Yes, I agree it is about contracts, but this leads to the discussion of what exactly is a contract that provides the value necessary to truly be useful to the consumer.... In my experience there are multiple orders of magnitude between what is typically produced as a contract [by the publisher] and what is needed by the consumer to determine the impact on their usage.

I am certain this is an area of improvements, and this is why semantic versioning is only at version 2.0.0 right now! To do so, we could explore different canonical unintended breaking changes between minors that happened in software history, where the interpretation of the contract was at stake. And from there, extrapolate a taxonomy of contracts and library purity.

What I mean by library purity is close to purity in functional programming: if you only expose functions with no side effects, the library is pure. If your library instantiates a singleton in the global namespace, it is unpure. If it rely on non-javascript, environment-specific binaries, it is environment-coupled. But I am sure we could go way further in describing what could be called the library footprint.

From that library footprint exposed to public knowledge, leveraging the impact of a library update would be easier.

@calidion

This comment has been minimized.

Copy link

commented Feb 8, 2019

@jsamr

You move from assumptions, contracts to communicating.
But you still don't realize the fact.

Science and technologies draw principals from facts not from thinking, from what it is instead of what it should be.

I think computer should based on decimal but it is binary.

I think programs should be bug free but it will never be.

If the fact is ignored, what is the value of finding communicating methods?

Semver bears a good will, but it will never be a realistic one.

A false good will always lead to a bad result.

Npm's auto update has shown the downside and now lock fill has be introduced for remedy.

I don't know why you still insist on use semver, what benefits do you gain on applying semver?

Get sky high version number?
Make versions meaningless?
Upgrade major version on every small change that breaks?
Auto updates that makes software unstable?

I think there must be a list of gains if semver should be adopted.

I apologize for using stupid if it is offensive.

Software quality will not be improve by merely defining very strict rules.

@jsamr

This comment has been minimized.

Copy link

commented Feb 8, 2019

@calidion Perhaps the language barrier has an incidence, but I don't think you really grasp what I am attempting to express... If you want to continue this discussion, please drop a mail (see my profile to get the address).

xfix added a commit to xfix/Pokemon-Showdown that referenced this issue Feb 23, 2019
Using a tilde in a version number as TypeScript explicitly doesn't
follow semver according to microsoft/TypeScript#14116.
xfix added a commit to Zarel/Pokemon-Showdown that referenced this issue Feb 23, 2019
Using a tilde in a version number as TypeScript explicitly doesn't
follow semver according to microsoft/TypeScript#14116.
TheJetOU added a commit to TheJetOU/Pokemon-Showdown that referenced this issue Mar 4, 2019
* Gen 1: Paralysis should not reapply stat drop because of a failed move (Zarel#5123)

* Random Battle: Fix Dedenne HP EVs (Zarel#5122)

* Mafia Theme Update (Zarel#5114)

* SSB: Fix Compost & Wonder trade with False (Zarel#5124)

* Support custom rated messages

(For use in SPL)

* Fix dc6fc43

* Scavs: Award points for hosting automatically (Zarel#5126)

* Mafia: Bugfixes for modifiers, allow searching for terms (Zarel#5127)

* Better fix for dc6fc43

* Battle Factory: Split UU Hydreigon sets

* Let's Go OU: Remove suspect notice

* PU: Ban Alolan Exeggutor

* Fix crash, message for locks (Zarel#5125)

* Datacenter: Add more ranges (Zarel#5129)

* Battle Factory: Fix another Hydreigon set

* NU: Add Vanilluxe suspect notice

* Add ORAS 1v1 and DPP AG

* Update Trick Room's short description

* Add 2nd and 3rd place point information to trivia modlog

* Remove a comment in Trivia code about point values

They no longer need to be divisible by 5. The caps are unlikely
to change, however the technical limitation of values having to be
divisible by 5 no longer exists.

* Notify after, not before, deleting a help ticket (Zarel#5130)

* Update CAP analysis links

* Support new avatars

This isn't full support, but it's the important part, the part that lets
you use past-gen avatars.

* Other Metagames of the Month February 2019 (Zarel#5131)

* Add February RoA Spotlight

* Fix 'sage-gen2jp' avatar

* Update allowed avatars list

* Remove Pokebilities format

I'm no longer accepting non-TypeScripted formats.

* Fix missing comma

* Remove useless param from pokemon.transformInto

Introduced in 743c851

* Stadium: Fix Counter and probably other things

* Remove Simple Symphony

* Always display Alola formes in /ds (Zarel#5133)

The Alola formes are so different to regular formes that displaying
both the regular form and Alola form is actually a useful
information.

* Fix some OMotM crashes (Zarel#5132)

* Deprecate battleban

* Fix unnecessary ts-ignore

* Pokebilities: Ban Moody (Zarel#5136)

* Update Me First

* Spotlights: Allow non-staff to see current spotlights

* Spotlights: allow multiline input

* Remove useless check from pokemon.transformInto

* Remove useless check

* Make it harder to timerstall

This commit is aimed at a particular kind of timerstalling: starting a
new game while letting the timer run out on your current game, instead
of just forfeiting.

Now you can't search for more battles if it's your turn to move, or if
your opponent takes less than 10 seconds to move (including animation).

1v1 and Metronome Battles asked for exemptions, and they've received
them.

* Pikachu-Alola is not an Alola form for dex search (Zarel#5138)

The intent of a recent dexsearch change was to display Alola formes
separately as they are very different. However, this also meant showing
Pikachu-Alola which is not an Alola form despite having "Alola" as
a forme name.

* Gen II: Fix species items

* Reorder formats

* Formats: Fix typo and add more thread links

* Update command documentation (Zarel#5128)

* Move server code to server/

Also move mods/ to data/mods/

This makes PS more monorepo-like. The intent is to further separate
the sim and the server code, but without fully committing to splitting
the repository itself.

We now support `./pokemon-showdown start` in addition to
`./pokemon-showdown`. I'm not clear which I want to be the default
yet.

* Fix formatText support for `&` `>` etc in URLs

* Fix StaticServer and loading rooms

* Revert url for chatrooms.json updates

* Fix Illusion when dragged out

* TypeScript globals

A few globals: Monitor, LoginServer, etc weren't being correctly
TypeScripted. This should change that.

* Datacenters: Add a range (Zarel#5141)

* Fix Hotpatch

* Fix the rest of the hotpatches

* Add BH suspect test

* Rename channel -> room, subchannel -> channel

"channel" is just a fancy way of saying "room, but in sockets".
Renaming them like this should make it clearer exactly what's going
on in sockets.

* Fix some LGTM alerts (Zarel#5139)

* Pokebilities: fix special abilities as well as Gastro Acid (Zarel#5140)

* STABmons: Ban Thundurus

* RU: Ban Stakataka

* Help tickets: Remove timerstalling

* Battlesearch improve UI

* LC: Ban Baton Pass

* Check capitalization in Factory sets

This might be debatably important, but if it's worth pointing it out
in reviews, we might as well automate it.

* Use `declare let` instead of `let` in globals.ts

* Fix chat plugin file I/O after server/ refactor

* Fix modlog search location

* Battle Factory: Update RU and LC (Zarel#5143)

* Fix hotpatch uncaching

Chat.uncache functions now consistently take a path relative to repo
root, just like FS.

Next step will probably be to have FS handle all text-based databases.

* Fix crash in /data

* Mafia: Support hiding discards, starting from open signups (Zarel#5142)

* Refactor Emoji regex to use \p syntax (Zarel#5146)

(Increases minimum Node version requirement)

* Increase required version number in README

* Suppress LGTM's URL sanitization warning (Zarel#5147)

This warning is strictly speaking correct, the URL isn't verified
properly. However, in this case, this isn't a practical issue, as
it's possible to use /forcebattleban command anyways.

* Add Recoil as Move Search Parameter (Zarel#5149)

* Help Tickets: Require users to explain their issue before getting help (Zarel#5148)

* Fix ticket activation when the creator is staff

* STABmons: Fix Thundurus ban (Zarel#5150)

Only the base forme was supposed to be banned.

* Formats: Fix thread links

* Movesearch: Account for custom recoil (Zarel#5151)

* README: Add notes on upgrading Node version

This should help Linux users.

* Add LGTM alert count badge (Zarel#4843)

* Allow free multi-laddering in first five turns

Searching for multiple games in the first five turns is unlikely to be
timerstalling, so we allow it here.

* Improve choice error messages

This should make choice errors clearer.

* Fix crash in /processes

* Better support IPv6 in IP checker

* Fix minor typos

* Fix Help Tickets preview

* Add in-battle mod detection to /weak and /coverage (Zarel#5144)

* Clarify message for multi-laddering

* Fix hotpatching battles/formats

Hotpatching battles only is no longer possible - it takes the same
amount of resources as hotpatching formats but is way more error-prone.

* Remove 7 second limit for multi-laddering

* Automatically end `BattleStream`s at end of battle

PS prefers to keep battle streams open (for `/evalbattle`) until
manually ended, but this is confusing some other users. We now
automatically end streams unless the `keepAlive` option is set.

Fixes Zarel#5157

* Fix /hotpatch chat

Old chat plugin processes weren't getting correctly ended.

* Tweak ghost connection timeout, log their connection status

* Fix an edgecase regarding locks getting removed on guests
This caused /unnamelock to leave ghost users in the userlist

* Fix math for counting battle turns

Turns out, requestCount goes up by 2 every turn, not 1.

In hindsight, this makes sense because we're giving every player their
own request ID.

* Random Battle: Update Probopass (Zarel#5159)

Earth Power is one of its most used moves because of Steel trapping with
Magnet Pull, while Pain Split is almost unheard of in standard tiers,
and isn't very useful on it unless it has Sturdy (but Magnet Pull is the
better move and is rated higher)

* Refactor formeChange

This fixes an obscure issue where we sent a formechange-to-self on
faint in certain obscure situations (apparently including Gen 4
Custap?)

In case anyone wants to investigate the details (this commit just
patches over some symptoms), the relevant replay is here:

https://replay.pokemonshowdown.com/smogtours-gen4ou-425031

* Require object literal method shorthand

* Deprecate /redir

* NU: Ban Vanilluxe

* Remove deprecated commands from /help

* Random Battle improvements

* Mafia: Fix starting games through the UI (Zarel#5156)

* Add a PageContext for HTML pages and expand html page functionality (Zarel#5160)

* Show deprecated status of commands in the command help

* This command is not technically deprecated but close enough

* Support the random battles damage calculator

* Random Battle: Update Rhyperior (Zarel#5162)

* Random Battle: Update Rhyperior

- Although Rock Blast is the preferred move in RU, there are notably
fewer Sturdy mons in Random Battle and it struggles more with breaking
Substitutes with it.
- Aqua Tail gives very minimal meaningful coverage since it mostly is
super effective on Pokemon already weak to Ground. Instead, give it Ice
Punch since it's much more common on it.

* Update formats-data.js

* Update formats-data.js

* DPP LC: Ban Hypnosis

* Battle Factory: Remove unranked Pokemon and fix Snorlax (Zarel#5164)

* Revamp evolution tables (Zarel#4997)

* Add LC suspect notice (Zarel#5169)

https://www.smogon.com/forums/threads/lc-suspect-bush-doesnt-care.3647220/

* Change (PU) to Untiered (Zarel#5170)

* Prevent using Leppa Berry from triggering Endless Battle (Zarel#5158)

Previously, using Leppa Berry by itself caused Endless Battle Clause
to consider Pokemon to be stale. However, it is reasonable to use
Leppa Berry without an intent to cause an endless battle - for
instance to increase the PP of a move with a low PP.

* Fix transformInto so OMs still work (Zarel#5165)

* Add tests for Sleep Clause Mod (Zarel#5171)

* Cafe: Fix path

* Fix terrain seed activation timing (Zarel#5163)

* CAP: Nerf Crucibelle-Mega (Zarel#5172)

* CAP: Nerf Crucibelle-Mega

* oops

* Revert "Fix terrain seed activation timing (Zarel#5163)" (Zarel#5173)

This reverts commit 250955e.

* Fix "Fix terrain seed activation timing (Zarel#5163)"

Shouldn't of reverted this so quickly. Credit to the code goes to @MacChaeger

* Add alias for /hidetext

* Add Bottle Caps

* Mafia: Fix html room updates (Zarel#5174)

* Battle Factory: Fix Espeon's ability in RU (Zarel#5175)

* Fix crash in ghost connection fix

* 1v1: Unban Kyurem-Black (Zarel#5176)

* Don't crash when using /data in with the camomons mod

* TCG: Update wiki domain

* Allow warning users outside the room in all global warn contexts

* Fix Chimecho's egg group

* Support custom hideReplay setting

* Use editprivacy permission for /ionext

This matches the permission for /ioo

* Update .gitignore for /server/

* Optimize Dex#getEffect by caching the result. (Zarel#5181)

As outlined by pkmn.cc/optimize, this change should result in a ~30%
increase in Battle performance over repeated runs. Caching the
resultant effect is safe provided nothing mutates it.

* SSB: Fix Evoblast interaction with substitute; update ranks (Zarel#5166)

* Learnsets: Fix Gen 4 tutor moves

* Refactor Dex#getEffect + Dex#getEffectInner back to one method (Zarel#5182)

* Add evolution method information (Zarel#5179)

* Improve data representation of evo method

* Simplify evo data representation

* Add 1v1 suspect notice (Zarel#5186)

* Disallow 0 EVs even when EVs weren't sent (Zarel#5187)

* Refactor remaining tests to use Battle#makeChoices (Zarel#5183)

* Remove * from most permissions shown in /help (Zarel#5168)

* Tours: Fix a forfeit being reported as failed even though it succeeded (Zarel#5188)

* Finally remove deprecated legacy API

It's gone! The last remnants of the old choice parsing system is
finally gone!

* Lower tab size in !code

* Chat monitor: make inap pokemon names weeklock instead of namelock

* Fix random typos in tests (Zarel#5190)

* Split `getRelevantEffectsInner`

This is mainly a readability refactor.

* Refactor getRelevantEffects -> findEventHandlers

This fixes getRelevantEffects's massively confusing call structure.

Most parameters relating to bubbling up and down have been removed
entirely, and traversing the many possible event handler types is now
simply done outside the callers.

In addition, a lot of variables/functions have been renamed for much
better clarity.

* Random Battle: Improve Toucannon

* Mafia: Resolve chat pages properly (Zarel#5192)

* Datacenters: Add a range

* Refactor findEventHandlers further (Zarel#5193)

- rename `thing` when we know what it will be.
- simplify `resolveLastPriority`
- remove `findBattleEventHandlers` param given that its always this
- avoid multiple lookups of the same attribute

These functions related to finding events are very hot
(pkmn.cc/optimize) and microbenchmarks indicate TurboFan is unable
to extract out the constants for us. As a side benefit, there's less
`// @ts-ignore` required, and future optimizations will use the
constants anyway. More extraction can be done in findEventHandlers,
but that will be left for a future change where the need becomes
more obvious.

* Mark Feebas's evolution in Gen4 as requiring high Beauty

Trade evolution for Feebas was introduced in Gen5.

* Remove 'server/process-manager.js' from tsconfig (Zarel#5197)

'process-manager.js' now lives under 'lib/' which is already
included.

* Add 1v1 Sample Teams (Zarel#5195)

* Add 1v1 Sample Teams

* Add missing comma

* Fix some Typescript related TODOs (Zarel#5198)

* Datasearch: Fix event Pokemon showing in LC searches (Zarel#5177)

* Document remaining message types in SIM-PROTOCOL (Zarel#5196)

* Add Imprison switch-out test

Apparently we had zero tests to make sure volatile statuses go away
after switching out and back in!

* Further improve switch tests

- Test that Baton Pass passes Ingrain
- Test that Baton Pass doesn't pass Imprison
- Test that other forms of switching don't pass either

* Update TypeScript to version 3.3.3333

Using a tilde in a version number as TypeScript explicitly doesn't
follow semver according to microsoft/TypeScript#14116.

* Pokebilities: Ban Porygon-Z (Zarel#5200)

* Refactor getFormat pattern and ordering for speed (Zarel#5194)

Even though 31c6a32 added caching to make this method less of a
hotspot, there's no reason to use a pattern which is an order of
magnitude slower (https://jsperf.com/pokemon-showdown-getEffect).
Also, rearranges Format to get checked first as pkmn.cc/optimize
finds it to be the most frequently accessed.

* Revert "Refactor getFormat pattern and ordering for speed (Zarel#5194)"

This reverts commit 9ce0066.

It doesn't account for bugs relating to Object.prototype

* Refactor getEffect for speed safely (Zarel#5201)

Rollforward of 7a20245 which retains the `hasOwnProperty` checks.

Also changes the method to call `toId` earlier and use the id
as the key to the cache to ensure 'Stealth Rock' and 'stealthrock'
return the same. NOTE: 'move: Stealth Rock' and 'Stealth Rock' will
still continue to return different results.

* Translation support (Zarel#5167)

* Fix field initialization ordering in Pokemon (Zarel#5204)

* Random Battle improvements

* Random Battle: Properly increment tier counters

* Gen I: Stop trying to change a fainted Pokemon's stat stages

* Make sure Transform copies the correct type

* Cleanup tsconfig includes further (Zarel#5202)

* Remove BH suspect

* Fix misplaced string in PT translation

* Fix an inaccurate simplified Chinese translation (Zarel#5208)

Bumba's OS not showing those characters somehow

* Revert "Change (PU) to Untiered (Zarel#5170)"

This reverts commit d40fe51.

* Formats: Update ladders

* Change Untiered to (DUU) for Doubles (Zarel#5178)

* Don't add inactive rules as pseudoweathers (Zarel#5206)

* Fix crash with PMs

* Pokebilities: Update Trace, Power of Alchemy, and Receiver (Zarel#5203)

* Pokebilities: Update Trace, Power of Alchemy, and Receiver

Now Trace copies a random ability from a random target, regardless of whether it was originally an innate or not

* Send correct target in message to client

* Fill in Japanese aliases (Zarel#5209)

* Fix Gen 1 bug involving last damage and Substitute (Zarel#2598) (Zarel#5211)

* Fix Counter/Mirror Coat to respect redirection (Zarel#5212)

* Refactor `sim/` to be native Typescript (Zarel#5210)

* Include data/mods/gen1/pokedex.js in tsconfig (Zarel#5213)

* Add GSC NU

* Translations: fix missing english strings

* Add one more volatile switch test

* Run onModifyTemplate on rulesets (Zarel#5207)

* SSB: Arrested -> Pablo; Fix Fake Claim & Sub Interaction (Zarel#5205)

* Fix build/hotpatch process

Hotpatching and running `./pokemon-showdown` now automatically run
`./build`. There should now mostly not be any reason you'd want to
manually run `./build`, except if you're invoking tests directly.

In addition, a lot of redundant code has been removed.

I'm not 100% sure this works on Windows, but I'm sure I'll get reports
if anything breaks.

* Explicitly import readdirSync in dex.ts

This avoids ExperimentalWarnings caused by wildcard import of fs.

* Update Psych Up and Transform interactions with crit rate effects

* Datacenters: Add a range

* Make !rules broadcastable

This fixes a regression.

* Fix fs.promises warning properly

The modern `__esModule` fallback isn't compatible with Node, and also
entirely unnecessary in practice.

The approach of disabling all the fallback code allows us to once again
`import * as fs`.

* Fix crash in SSB import

* Fix Shell Trap behavior with Encore (Zarel#5218)

* March RoA Spotlight

* Make modlog asynchronous

This should prevent issues in which the /modlog takes forever
because it's waiting for previous /modlog command.

* Log long modlog queries

* Rephrase LICENSE

GitHub couldn't identify the old license as the MIT license,
so I'm just copy/pasting the one from the damagecalc which
GitHub doesn't have a problem with.

* RU: Add Zygarde-10% suspect notice

* Datacenters: Add more ranges

* Random Battle fixes

* Update Other Metagames

* Make sure suspect notices only show up in the relevant format

* Update VS Code launch configurations

- Remove "start server" because it's incompatible with multiprocess PS
- Add "parse input log"

* Fix Other Metagames of the Month (Zarel#5224)

* Tiers: Add March quick drops

* Added RBY UU (Zarel#5225)

* Add BW Monotype

* Megamons: Ban Mega Rayquaza

And remove some unnecessary validator checks.

* Change the RoA Spotlight

DPP Ubers was wrongly announced.

* Pull large avatarTable out into a Set constant. (Zarel#5228)

* Remove FIXME's in gen1/gen2 random-teams.js (Zarel#5227)

* Fix /dt showing 'undefined' as Zygarde ability (Zarel#5153)

* Refactor `lib/` to be native Typescript (Zarel#5217)

* Random Battle: Improve Kyurem

* Fix Megamons and Chimera simplistically (Zarel#5229)

* Remove LC suspect notice (Zarel#5231)

* Update RU thread links (Zarel#5230)

* Refactor sim/dex-data.ts to minimize @ts-ignore (Zarel#5214)

* Fix crash in Anticipation (Zarel#5232)

A battle has crashed: TypeError: Cannot read property 'fainted' of null
at Battle.onStart (/home/ps/showdown/data/abilities.js:150:16)

* Fix Protean and Color Change (Zarel#5233)

* Fix dependency check in build script

(This error wasn't caught because it still works without installing
the dependency, but makes the build script far slower because
`npx replace` would reinstall `replace` every time it's used.)

* Fix validation of Gen 2 Marowak set

This was a lot of work for what turned out to be a really simple fix.
Gen 2 tradeback validation ended up being slightly too strict.

* Use array spread instead of Array.from

* LC: Unban Torchic (Zarel#5234)

https://www.smogon.com/forums/threads/torchic-has-been-freed.3647800/

* Disallow non-standard Pokemon in Gen1/2 randbats (Zarel#5235)

* Revert buggy Megamons "fix" (Zarel#5236)

* Fix HP bug in Chimera (Zarel#5237)

* Use FS when loading Scavengers' data (Zarel#5238)

This prevents issues with loading old state while hotpatching.

* PU: Add Houndoom suspect notice

* Chimera: Fix remaining HP bug (Zarel#5240)

* Fix `build` script on Windows. (Zarel#5241)

On Windows,	`shell` doesn't glob for us and the literal
`.sim-dist/*` is passed to `replace` and it doesn't get expanded
into the list of paths.

* Chimera: Fix ability bugs (Zarel#5244)

* Add suspect notice to Mix and Mega

* Add Type: Null to Random Battle

* Megamons: Fix bans
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.