Is there a way to ensure that the any type isn't used within a file? For instance, if a third party library doesn't have type definitions, meaning its imports have the any type, I'd like a warning or error.
You could try to use flow-typed along with eslint-plugin-flowtype. (I never tested this, but maybe it works)
flow-typed downloads typedefs for your dependencies from a repository, and generates empty type definitions for the ones missing from the repo.
By empty, I mean it will generate typedefs with any types everywhere.
eslint-plugin-flowtype has a no-weak-types option, that warns against the use of weak types (any, Object and Function) in your files.
Maybe you could configure eslint to check the files generated by flow-typed, and you would get warnings every time a any type appears in those files.
Related
I have added django-model-utils to an existing (large) project, and the build is now failing, as part of the build includes static type checking with mypy.
It complains that models that I have added objects = InheritanceManager() to, don't have attributes for reverse ForeignKeys, if the reverse FK is accessed in a method on that model. For example, take the following:
class Student(Model):
school = ForeignKey(School, related_name='students')
class School(Model):
objects = InheritanceManager() # IRL School is a subclass of some other model
def something(self):
return self.students.filter(...)
Then running mypy on it, will return:
error: "School" has no attribute "students"
And even if I remove the related_name, and use self.student_set (i.e. the default django relation), it will still produce the same type of error. Only removing the InheritanceManager fixes the static type checking. Of course, I'm using it for a reason as I need to select_subclasses elsewhere in the code.
Has anyone come across this, or have a fix?
django-stubs uses plugin to add all managers. This plugin is triggered only if added manager is a "subclass" (not just real subclass, but also recognizable by mypy as such) of models.Manager.
django-model-utils is untyped, so InheritanceManager is in fact Any for mypy, and plugin does not see it. To solve exactly this issue I was adding py.typed marker to django-model-utils as a CI stage after package installation. You can also use a fork with py.typed or create a stub package for django-model-utils. This can result in other issues and doesn't give good type checking (all unannotated methods have Any as implicit arguments and return type), but is better than nothing. For my needs the marker was sufficient.
py.typed marker is an empty file located in package root (venv/lib/.../django_model_utils/py.typed) - it tells mypy that package does not need separate stubs and contains all necessary types.
In short: I have a method name provided via a JSON configuration file. I'd like to call a method using this provided name. The method (with a matching name) will exist in the backend. What's the best way of going about this?
I am not quite sure what I should be searching for as an example.
To detail: I am working with a legacy application, hence the VB.NET. I am building a single PDF file from multiple PDF sources. Most of these are as is, I simply read the configuration and grab the relevant files and the job is done. However some require processing, I'd like the configuration file to pass in a method name to be called that will perform extra processing on the PDF, whatever that may be.
As there can be a lot of PDF files that can vary, I cannot simply use a property such as "PostProcessing: true".
Any ideas?
You could use reflection to reflect method names back and check them against the name passed from the property in the config file.
Like so
Type magicType = Type.GetType("MagicClass");
MethodInfo magicMethod = magicType.GetMethod("ItsMagic");
object magicValue = magicMethod.Invoke(magicClassObject, new object[]{100});
That would work.. but to be honest, I'd go with a case statement as you'll be hardcoding the method names anyway (because they are code), and it'll be strongly typed (less chance of typos and errors).
Just noticed that there are two name settings in any Typesafe Activator template - one in build.sbt and another in activator.properties.
Is there a way to make one depend on (use the value of) the other? Although the build's name can be defaulted to the name of the main project folder, I'm not sure about the activator's.
You could make build.sbt write out or modify activator.properties, using whatever scala code you want to use for that.
But you'd still have to check activator.properties in to git because the Activator template-publication system does not run sbt on the project, it just looks at the files in git.
And also your nice template intended for end-users would end up with some extraneous build code in it to generate activator.properties, which would clutter up the example.
You could try going the other way but I think it won't work.
In sbt, name is a setting rather than a task, and is thus evaluated only once -- so if you made it read from activator.properties, you'd need to restart (or at least reload) your sbt build whenever you edited activator.properties. But you could read from activator.properties using whatever scala code you like. Something like:
name := {
val props = new java.util.Properties()
props.load(new java.io.FileReader(file("activator.properties")))
props.getProperty("name")
}
However, this is going to fail for two reasons.
When a template is instantiated (cloned) by an end user:
activator.properties is dropped
activator tries to replace the name in build.sbt with a user-selected one
So on clone, first the above code would fail due to missing activator.properties, and second the user's selected name wouldn't be swapped in (because the above expression is too complicated for activator to figure out how to replace it).
This name-replacement means your build.sbt name will get dropped in most cases anyway. The one exception is if the user downloads the "template bundle" (a pre-cloned zip of the project) from the template's detail page on typesafe.com, then the name in your build.sbt would be kept.
Note that if you ever change the name in activator.properties then you'd end up duplicating your template (you'd effectively be publishing a new template), so you may not want to abstract this anyway -- you should change it only when creating a new template is your intent.
Perhaps the bottom line is KISS -- write the name in two places. The alternatives are all going to cause headaches.
The only way I can think of to make this sane would be to have some code outside of the template which generated the template. Akka and Play both do this, I think, for templates that are part of the larger akka and play source trees. But at this point you're definitely doing more work than I'd do just to avoid copying one name string around, you'd want to have some other reason to go there.
Is it necessary to specify the document spec in SendPort flat file assembler property?
I have read some article saying it is NOT necssary as it will use the xml namespace to find the corresponding flat file schema to assemble the xml into flat file.
However, I have tried in our case (we are using 2006R2), but seems it is not ok, we need to specify the document spec in sendport assembler component property to make it works. Otherwise, it will say cannot find the schema from the target namespace.
Any idea?
Thanks.
No, it is not required to set the DocumentSpec for the Flat File Assembler.
FFDasm will first attempt to resolve the schema by the same process as the XmlAssembler, usually by namespace#rootnodename.
However, the same rules still apply and the most important is that the namespace#rootnodename must be unique within the BizTalk Group.
So, first, make sure only one of your FF schema is deployed.
I get JSLint errors in a file for undeclared functions and variables referenced from another file. Does brackets have a configuration/menu to remove these while keeping other linting errors?
JSLint complains whenever you reference an identifier that it can't see any declaration for in the file. So if you're using global variables/functions that were set by some other file, you'll get these warnings.
You can stop the warnings by individually specifying which undeclared globals you want to allow. To do that, place a directive like this at the top of your file:
/*jslint indent: 4 */
/*global ClassFoo, ClassBar, someFunction */
But of course, it's a pain to list things manually in each file.
Perhaps the best way to clean this up is to use a module loader like RequireJS. Then most your references to other files won't be through globals, and you'll only have to tell JSLint to ignore the few globals needed for RequireJS itself (usually just define).
Using a module loader has other benefits too. It eliminates "dependency spaghetti" by making cross-file dependencies very explicit, and it automatically load modules in proper dependency order. And there are easy tools that automatically concatenate all your modules into one file when you're ready for deployment.