-
-
Notifications
You must be signed in to change notification settings - Fork 11
DefinitelyTyped release #13
Comments
Please see the new |
@spacejack You said that you would ultimately want a UMD version and a ES6 module version. Are you still aiming for that? |
I think what we want is this UMD version and a global version for scripts? I'm going to try a global version that imports the UMD types then exports some customized global types so we don't have to copies of everything. Eg., building on this idea. |
Oops I think I missed your point... I suppose these types don't need to be UMD since they're not correct for global usage, they only need to work for module usage. So should probably remove the |
That line means the difference between |
Well the module version should be whatever name you use. So if you For the global version, everything should be on I'm playing around with a global version of types, but can't quite get it to work... I was hoping something like... import * as mithril from 'mithril';
import * as stream from 'mithril/stream';
declare const m: mithril.Static & stream.Static; |
Also trying this but it's not working, hmm... import * as mithril from 'mithril';
declare namespace Mithril {
type Lifecycle<A,S> = mithril.Lifecycle<A,S>;
type Hyperscript = mithril.Hyperscript;
type RouteResolver<S,P> = mithril.RouteResolver<S,P>;
...
}
declare const m: Mithril.Static; |
All right, I think I have it. This seems to work: // mithril-global.d.ts
import * as mithril from 'mithril';
import * as stream from 'mithril/stream';
declare global {
namespace Mithril {
type Lifecycle<A,S> = mithril.Lifecycle<A,S>;
type Hyperscript = mithril.Hyperscript;
type RouteResolver<S,P> = mithril.RouteResolver<S,P>;
...
type Stream<T> = stream.Stream<T>;
type Static = mithril.Static & {stream: stream.Static};
}
const m: Mithril.Static;
} Then usage is: // test.ts
let c: Mithril.Component<{},{}>
m(c, ...)
let s: Mithril.Stream<number> = m.stream(1) |
Ugh, no, we should be using UMD style for global usage. Sigh... // mithril-global.d.ts
import * as mithril from 'mithril';
import * as stream from 'mithril/stream';
declare namespace Mithril {
export type Lifecycle<A,S> = mithril.Lifecycle<A,S>;
export type Hyperscript = mithril.Hyperscript;
export type RouteResolver<S,P> = mithril.RouteResolver<S,P>;
//...
export type Stream<T> = stream.Stream<T>;
export type Static = mithril.Static & {stream: stream.Static};
}
declare const Mithril: Mithril.Static;
export = Mithril;
export as namespace m; Script usage: // test.ts
let c: m.Component<{},{}>
m(c, ...)
let s: m.Stream<number> = m.stream(1) Now you have minimal differences between script and module app code. |
How about importing with |
I have created a new branch: dt-module which is now exclusively for module use. (This simply removed the On the Finally, here is a test repo for the global types. This repo includes a small but necessary additional types file in the case that you are writing modules but are including mithril.js as a standalone script file. See the test.ts file for notes on the nuances. This accommodates all 3 forms of usage as best as I can see at this point. Let me know if you think there are any possible improvements yet. |
@spacejack Looks great! |
Previously you'd indicated that mithril.d.ts was going to be moved into mithrild.js project itself, is that still on the road map? |
Hi @winksaville, sorry, plans have changed. We'll be submitting to DefinitelyTyped instead. It will be easier to maintain if the release cycles are decoupled, plus makes it easier to switch between type definitions if a user prefers. These are the types that will be submitted: https://github.com/spacejack/mithril.d.ts/tree/dt-module and for now can be installed with:
|
That's to bad from my perspective, but TXS.
What's the schedule for submitting to DT?
…On Mon, Mar 27, 2017, 1:12 PM spacejack ***@***.***> wrote:
Hi @winksaville <https://github.com/winksaville>, sorry, plans have
changed. We'll be submitting to DefinitelyTyped instead. It will be easier
to maintain if the release cycles are decoupled, plus makes it easier to
switch between type definitions if a user prefers.
These are the types that will be submitted:
https://github.com/spacejack/mithril.d.ts/tree/dt-module
and for now can be installed with:
npm install -D github:spacejack/mithril.d.ts#dt-module
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#13 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA-hHKKFVPTrt88jVEjBNRnnfoUcqKn_ks5rqBg0gaJpZM4MpHt2>
.
|
Mithril 1.1 was released today. I've merged the working branches into master for mithril.d.ts and mithril-global.d.ts. See the readmes in the respective repos for current install urls. Time permitting, I'll try to prepare a PR for DefinitelyTyped tomorrow. |
Would it be correct to say that as a Typescript user I should not upgrade
Mithril until the corresponding @types/mithril.d.ts is added to DT?
…On Mon, Mar 27, 2017 at 7:54 PM spacejack ***@***.***> wrote:
Mithril 1.1 was released today. I've merged the working branches into
master for mithril.d.ts <https://github.com/spacejack/mithril.d.ts> and
mithril-global.d.ts <https://github.com/spacejack/mithril-global.d.ts>.
See the readmes in the respective repos for current install urls.
Time permitting, I'll try to prepare a PR for DefinitelyTyped tomorrow.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#13 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA-hHK11tZ24lR_Pdp9GB-U18rjnsusIks5rqHZ1gaJpZM4MpHt2>
.
|
Well, trigger pulled! PR is here. Had to make some organizational and config changes to conform to DT's repo. Would like to roll those changes back into this repo in order to make future work easier to create PRs for. @winksaville It's up to you. I don't think there are any plans to change the definitions unless DT rejects us for some reason. So you should be able to simply switch your package.json to point from here to npm. I'm not sure how long it'll be before the new types appear on npm assuming the PR is merged, but I'm sure several days at least(?) |
I added a trivial d.ts to DT recently and it was available immediately
after merging, IIRC. Anyway, having the d.ts in the Mithril repo eliminates
coordination, so I'm disappointed it not in there, but so be it.
Out of curiosity, did you want to keep mithril.d.ts separate or was that at Leo's request?
…On Tue, Mar 28, 2017, 6:05 PM spacejack ***@***.***> wrote:
Well, trigger pulled! PR is here
<DefinitelyTyped/DefinitelyTyped#15467>.
Had to make some organizational and config changes to conform to DT's
repo. Would like to roll those changes back into this repo in order to make
future work easier to create PRs for.
@winksaville <https://github.com/winksaville> It's up to you. I don't
think there are any plans to change the definitions unless DT rejects us
for some reason. So you should be able to simply switch your package.json
to point from here to npm. I'm not sure how long it'll be before the new
types appear on npm assuming the PR is merged, but I'm sure several days at
least(?)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#13 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA-hHKpSAbCkQhdD9ndISHhylCKgqDlHks5rqa5qgaJpZM4MpHt2>
.
|
Types have been merged! You can now install from npm with:
|
@andraaspar: It looks like Mithril 1.1 will be released on Monday, so I'd like to prepare a PR for DefinitelyTyped that's ready to go when mithril releases.
Stream layout has changed a bit -
scan
andscanMerge
functions are now included instream
rather than separate modules.I'm going to rename
tests
totest
. Convention seems to be either put all tests inmodule-tests.ts
or to include atest
folder.To do this I'm going to fork
improved
(which should remain compatible with the current mithril 1.0.1 release) todt-umd
.The text was updated successfully, but these errors were encountered: