Using with typescript?

[grofit]

Hey I have just picked up an older project to do some more work on it and I keep getting errors saying that assign and sortBy etc are not found. To my knowledge you package a sugar.d.ts with the project that should get picked up (and does seem to get resolved) but it doesn't seem to use the extensions defined in there.

Can anyone provide a succinct example of using it as a module within the TS world?

I assumed I would just need to do:

import "sugar";

let sortedUsers = users.sortBy((x) => { return x.age; });

Have also tries import * as Sugar from "sugar" and done the Sugar.extend() not sure if that is needed per file in a module or just once somewhere in the module, but either way that doesn't seem to satisfy the typescript compiler.

My errors look like:

error TS2551: Property 'sortBy' does not exist on type 'ISomeInterface[]'. Did you mean 'sort'?

Using Sugar: 2.0.4
Using Typescript: 2.4.2

Also these errors crop up:

C:/.../node_modules/sugar/sugar.d.ts(929,50): error TS2304: Cannot find name 'Map'.
C:/.../node_modules/sugar/sugar.d.ts(933,47): error TS2304: Cannot find name 'Set'.

[grofit]

Ah right, so including lib: [ "es6" ] stopped the errors with sugar.d.ts but the rest of the errors still apply.

[andrewplummer]

There should be a sugar-extended.d.ts that you have to manually include via a triple slash directive. As not everyone uses Sugar in extended mode, the declarations are not included by default. Typescript has no way to know if new definitions are applicable at runtime. Note that the entire Typescript area of Sugar is being worked on right now, but this should not change in future versions.

[grofit]

ok, so the actual Sugar.extend() should I be doing that once per file or just once in the entire module?

[andrewplummer]

Provided everything is in the same runtime environment, then Sugar.extend should only be called once... However, modules can be extended separately such as Sugar.Array.extend(), in which case they can be called as needed.

[grofit]

ok thanks, have added the reference and it is all working, although sortBy seemed to have some odd behaviour as myTypedArray.sortBy<TypeOfArray>( (x: TypeOfArray) => { return x.someField; }); threw an error as it didnt resolve to a string or the sortFn type.

[grofit]

hmm right so first problem, so I added the path to the sugar stuff as requested:

/// <reference path="../node_modules/sugar/sugar-extended.d.ts" />

This works fine in lib-a however when this is pushed up and lib-b depends on lib-a it breaks because it will be trying to resolve relatively. Is there no way we can do import "sugar/sugar-extended" or something as the old reference style is being phased out (to my knowledge).

If there is no quick fix is there a recommended way to make the reference path work fine in projects dependent on the one that includes the path, as the relative paths wont always be correct, and adding a base path or something to a project just for sugar seems overkill.

[andrewplummer]

Hmm... I'm not sure exactly what you're doing, so it's hard to identify a quick fix. Ideally an app should have one entry point and Sugar should be both required and extended there. This is more or less a hard requirement for using Sugar in extended mode, as modifying the global state is something that only makes sense to do once. If for some reason Sugar needs to be used in multiple places that cannot share a common entry point, then I would argue that it's incorrect to use extended mode because it could potentially affect other areas of your application where you are not intending/expecting the global state to change as by definition you are requiring it further down the chain.

[grofit]

Thanks for getting back to me, so the scenario I have here is there is a library (not an application, just a module for re-use in other projects), and that uses sugar for things like sortBy and a few other methods. Like you say there is one file in the project which has this:

/// <reference path="../node_modules/sugar/sugar-extended.d.ts" />
import * as Sugar from "sugar";
Sugar.extend(); // or whatever the method is

So like you say there is one place where it does the whole inclusion and extending for sugar, and it needs the reference path otherwise stuff inside the project just throws errors where there is any sugar methods (i.e sortBy).

So anyway the above works in that module, but when I build that module (compile ts and generate d.ts) and publish it, and then go to consume it in some other library/app, as its exported the reference path, it would import that in the consuming app and blows up as the reference is not in the same place.

So to simplify moduleA uses sugar and has the reference path, moduleB consumes moduleA which then when compiling throws an error because the reference path wont be the same.

[andrewplummer]

I'm going to circle back to TypeScript issues soon, I'll have a look at that when I do.... thanks!

[javnov]

Hi @andrewplummer any news on this? The definitions could use the latest typescript features to be more "typed"

[andrewplummer]

Yes lots coming on this one. Typescript will be fully supported.