In this module I use the Alloy "div":
module test
one sig Test {
t: Int
} {
t = div[4,2]
}
run {}
Executing that works fine.
I created another module, which uses the first module:
module hope
open test
sig A {}
run {}
Executing that results in the following error message:
The name "div" cannot be found.
Why am I getting the error message? How to fix it?
It's a known bug with a simple workaround. You need to explicitly import the util/integer module in your first model.
See Alloy built-in integer math functions don't work in imported files
Related
I can't seem to grasp what is this actually about.
how can I create typings for this basic library? https://github.com/deanilvincent/check-password-strength/blob/master/index.js
This is what i've got so far:
declare module 'check-password-strength' {
function check_password_strength(password:any): any;
export = check_password_strength;
}
But how does it work? The Library is called check-password-strength. How is it possible, when I create function with check_password_strength, to still work? (Yes, this code actually works.)
I use it like this:
import check_password_strength from 'check-password-strength'
check_password_strength(body.password)
The problem is, except that I don't get why is it working with _ instead of - (- is not working though) I can't make functions with -. How does typescript know, that it should call the function? The next question I have, how can I change my d.ts file above to actually give me the right return type (for intellisense).
It returns tuple which looks like this:
strength = {
id: 2,
value: 'Strong'
}
How can I implement it in my code above?
I found the solution randomly for my question number 2. I still don't know however, how is it possible for typescript to call check-password-strength , when I use _.
The answer is:
function check_password_strength(password:any): {id: number, value: string};
I have a TypeScript source file that has the following import:
// myCode.ts
import * as x from 'dep';
...
export class myClass {
...
}
where dep is a Node package that's included as part of the npm install. myCode.ts is a simple class that just has three methods. I would like to mock the entire myClass from inside a Jest test script that is written to test another class, myMainClass.
The problem I'm having is that the dep code is running some initialization that I can't seem to bypass. The initialization code fails outside the "real" environment so I simply want to bypass this for test purposes. No matter what I try I get an error that looks something like this:
Test suite failed to run
Dynamic Linking Error: ... error text ...
5 | // myCode.js
> 6 | import * as x from 'dep';
| ^
Again, the error is expected since I don't have these libraries locally (and don't want them for unit testing).
I was hoping I could add a simple mock statement (e.g., jest.mock('myClass'), or something similar, that would bypass anything to do with myClass. That way the code causing the link error would not be executed.
I'm fairly new to using Jest. Hopefully, this is a simple ask and I'm just missing the obvious. Thanks for the help.
I can't find TypeScript definition #type/{name} for one of my installed NodeJS packages, so I attempt to write a d.ts file for it, and put the file in {project root}\typings folder. This is how I do:
// My source code: index.ts
import Helper from 'node-helper-lib';
// My definition: \typings\node-helper-lib.d.ts
declare....(something else)
declare module 'node-helper-lib' {
class Helper { ... }
export = Helper;
}
However, Visual Studio Code keeps yielding this error and puts red line under declare module 'node-helper-lib':
[ts] Invalid module name in augmentation. Module 'node-helper-lib'
resolves to an untyped module at '{project
path}\node_modules\node-helper-lib\index.js', which cannot be
augmented.
Isn't it legit that because the library is untyped, so I should be allowed to add typing to it?
UPDATE:
I am using:
TypeScript: 2.1.4
Visual Studio Code: 1.9.1
Node JS: 6.9.4
Windows 10 x64
The actual solution is given in a comment by #Paleo in #hirikarate's answer:
Imports should be declared inside the module declaration.
Example:
declare module 'node-helper-lib' {
import * as SomeThirdParty from 'node-helper-lib';
interface Helper {
new(opt: SomeThirdParty.Options): SomeThirdParty.Type
}
export = Helper;
}
After some tries and errors, I found that augmentation means "declaring a module in the same file with other module declaration(s)".
Therefore if we want to write a definition file for an untyped 3rd-party JavaScript library, we must have ONLY ONE declare module 'lib-name' in that file, and 'lib-name' must exactly match the library name (can be found in its package.json, "name" property).
On the other hand, if a 3rd-party library already has definition file .d.ts included, and we want to extend its functionalities, then we can put the additional definition in another file that we create. This is called augmenting.
For example:
// These module declarations are in same file, given that each of them already has their own definition file.
declare module 'events' {
// Extended functionality
}
declare module 'querystring' {
// Extended functionality
}
declare module '...' { ... }
I leave my discovery here just in case somebody has same question. And please correct me if I missed something.
The issue for me was that I was trying to declare the module in a .ts file. I changed it to .d.ts and it all worked just fine.
I was getting that error message too. The issue for me was that I was trying to declare another module in an existing type definition file that had a module declaration in it. After I moved the new module declaration to a new file, the error went away.
I'm extending a chrome extension that is written in coffeescript and have come across this syntax:
Commands =
init: ->
for command, description of commandDescriptions
#addCommand(command, description[0], description[1])
availableCommands: {}
keyToCommandRegistry: {}
I'd just like to check the difference between this syntax and a class (which would be like this, hypothetically):
class Commands
init: ->
for command, description of commandDescriptions
#addCommand(command, description[0], description[1])
availableCommands: {}
keyToCommandRegistry: {}
Is it just that the former doesn't have a prototype? am I right in thinking that it's alright to call the methods on the Commands in the top, as in Commands.init(). The project I'm working in seems to use both syntaxes so I would like to be sure I understand the implications of each before I use one or another.
Thanks.
The primary implication of the first Command is that it is an Object, not a Function, so there is no way to stamp out instances of it directly.
It is a bit confusing that its init method includes commandDescriptions (which I can only expect is declared somewhere else) and #addCommand, which is not attached to the Command object. If Command didn't have #addCommand, I would expect that it is a singleton. But as a method that is not declared on Command is expected to be present, it looks like the group of functionality in Command is meant to be mixed into another class.
Edit:
To clarify, objects can have #variables. In the init function, you would reference availableCommands or keyToCommandRegistry as #availableCommands and #keyToCommandRegistry. However, in this particular example, #addCommand is not declared anywhere. I would have expected it to be declared as part of the Command object declaration, like:
CommandsA =
init: ->
for command, description of commandDescriptions
#addCommand(command, description[0], description[1])
availableCommands: {}
keyToCommandRegistry: {}
addCommand: (command, descriptionInfo, otherDescriptionInfo) ->
#Does some stuff
If you can find where addCommand is declared, it would help in understanding how Command is intended to be used.
Also of note: since Command is an object and not a class, the availableCommands and keyToCommandRegistry objects can be thought of as static class variables.
I've recently started working on a non-trivial project in CoffeeScript and I'm struggling with how best to deal with registering exports etc. I'm writing it in a very 'pythonesque' manner, with individual files effectively being 'modules' of related classes and functions. What I'm looking for is the best way to define classes and functions locally AND in exports/window with as little repetition as possible.
At the moment, I'm using the following in every file, to save writing exports.X = X for everything in the file:
class module
# All classes/functions to be included in exports should be defined with `#`
# E.g.
class #DatClass
exports[name] = item for own name, item of module
I've also looked at the possibility of using a function (say, publish) that puts the passed class in exports/window depending on its name:
publish = (f) ->
throw new Error 'publish only works with named functions' unless f.name?
((exports ? window).namespace ?= {})[f.name] = f
publish class A
# A is now available in the local scope and in `exports.namespace`
# or `window.namespace`
This, however, does not work with functions as, as far as I know, they cannot be 'named' in CoffeeScript (e.g. f.name is always '') and so publish cannot determine the correct name.
Is there any method that works like publish but works with functions? Or any alternative ways of handling this?
It's an ugly hack but you can use the following :
class module.exports
class #foo
#bar = 3
And then :
require(...).foo.bar // 3
The old
(function (exports) {
// my code
exports.someLib = ...
})(typeof exports === "undefined" ? window : exports);
Is a neat trick that should do what you want.
If writing that wrapper boilerplate is a pain then automate it with a build script.
What I'm looking for is the best way to define classes and functions locally AND in exports/window with as little repetition as possible.
It's impossible to do something like
exports.x = var x = ...;
without writing x twice in JavaScript (without resorting to black magicks, i.e. eval), and the same goes for CoffeeScript. Bummer, I know, but that's how it is.
My advice would be to not get too hung up on it; that kind of repetition is common. But do ask yourself: "Do I really need to export this function or variable and make it locally available?" Cleanly decoupled code doesn't usually work that way.
There's an exception to the "no named functions" rule: classes. This works: http://jsfiddle.net/PxBgn/
exported = (clas) ->
console.log clas.name
window[clas.name] = clas
...
exported class Snake extends Animal
move: ->
alert "Slithering..."
super 5