-
Notifications
You must be signed in to change notification settings - Fork 9
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
Improve API parameter types #41
base: main
Are you sure you want to change the base?
Conversation
to split data extraction from TS code formatting, and allow further improvements
- make some API parameters required, based on module information, - infer `action` and `format` parameter value depending on the params interface used - disable `tslint` rules in specific lines and not globally, so unintended error cas still be detected - add missing `fm` formats - fix some interfaces sharing the same name - sort interface to not mix up "action" and "format" interfaces
- use `ApiParams` instead of `UnknownApiParams` on functions doing an actual API query, since parameters need to be correct here, - do not auto-complete API params that API functions already specify - force some API params to be specified, when the functions throw an error if missing - remove JSON-format specific params, use `ApiFormatJsonParams` instead
feat: add more MediaWiki modules check other authors/commits at wikimedia-gadgets#41
Some methods of mwn (e.g. parseWikitext) provide a default value for |
At the same time, the "variant" property is missing. qiuwenbaike/QiuwenGadgets@6bd8000#diff-ad3705a25402295b5651e9eb78f318e7c91737361988b391165eeff64948fb32R12 |
Rewrite API queries to recursively retrieve all submodules, not only main modules and action=query submodules Not that a submodule hierarchy is built, so each submodule remembers where it comes from. This is not used for now, but will be used to fix some perfix & interface name issues in another commit.
Some websites may still be using Flow, but all types related to Flow have been removed in this change (including optional values of the The three interfaces Some properties should not strictly limit optional values (such as |
- make interface order deterministic, so alternatives are sorted alphabetically and submodules are next to their root module - fix action/format modules not being stored correctly in cache
check other authors/commits at wikimedia-gadgets#41
(note: some changes in this PR massively break existing modules, without providing any viable alternative or migration process, I'm still slowly working on it but for now I do not consider to re-open this proposal, don't hesitate to re-use it or open new ones)
The goal of this PR is to improve parameter auto-completion of API functions. Various type changes are proposed in this PR, and some of these changes are not backwards compatible, as specified below.
Non-backwards-compatible changes:
json
,jsonfm
andrawfm
).ApiParams
instead ofUnknownApiParams
on functions doing an actual API query,action
property and various properties of action parameter interfaces,token
parameters are left optional for now, since I'm not sure whether these should be required or not, for strictness or ease of use.title
orpageid
parameters withaction: "protect"
, so currently omitting both will erroneously typecheck).action
andformat
parameter type in specific parameter interfaces,ApiBlockParams | ApiUnblockParams
only allowsaction: "block" | "unblock"
.ApiParams
interface,ApiFormatJsonParams
interface specify those parameters, so if we want to useApiMoveParams
with JSON-specific parameters, we can useApiMoveParams & ApiFormatJsonParams
.Backwards-compatible changes:
action > format > list/meta/props
.tslint
rules on specific lines and not for the entire file, so unintended error cas still be detected.api.create
takes the page title as argument, so there is no need to specify it in additional params,Note that to simplify the implementation of some of these changes, the
api_params
type generator has been significantly changed (mainly to separate data extraction functions from code formatting ones). This implementation is partially shared with the one of #40 (to simplify a potential future merge).