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.
Related
I am about to make my Custom Element <card-t> public
pre-release is at: https://github.com/card-ts/playingcardts
Suggestions and enhancements much appreciated!
Couple of questions:
Naming Custom Elements
There is: https://www.webcomponents.org/community/articles/how-should-i-name-my-element
but it doesn't get past "must include a hyphen"
I went with element.card-t.js for sorting purposes.
Other best practices ??
Wrapping in IIFE & ES Modules?
The Custom Elements gets created in the Global Namespace, and doesn't return anything like a library does.
Wrapping in an IIFE should be enough?
Is there value in loading it as module?
<script type="module" src="element.card-t.js">
Extending Custom Elements
Should we by default return the class definition so extending is easier?
Since this is an opinion question these are my opinions:
Naming Custom Elements
I always name my JS file based on my class name and my class name is just the tag name but capitalized. So my tag <my-thing> would have a class name of MyThing and my filename would be components/MyThing.js
Wrapping in IIFE & ES Modules?
I create all of my code in ES6+ and then I create an additional ES5 CommonJS version and an ES5 IIFE version and let people load what they want.
I use rollup and my component-build-tools to create my various versions. component-build-tools component-build-tools also combines all dependencies of a component into the output file. This can lead to some replication, but most of the time that is small enough I don't mind.
My components end up with their templates and locale strings embedded into the published files. This is a feature of component-build-tools.
Extending Custom Elements
As a general rule I expose the class name in all three formats of my files. This does help with extending my components, yet I doubt that many people will ever want to do that.
Where to place the files.
The hardest thing is where to place the files so they are easily accessed by the web page.
I have a build step that copies my files from the node_modules folder into a dist folder. This was the easiest thing for me to know exactly where my files are located.
Doing this allows me to npm install anything and then still get their files into a location I know and can use. But it also has lead to me not worrying greatly about where my files end up in my repo.
I do tend to have a dist folder and in there I have:
dist
+- js
+- components
+- MyThing.js
+- MyThing.min.js
+- AnotherThing.js
+- AnotherThing.min.js
+- SoOn.js
+- SoOn.min.js
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.
I want to use modules dynamically and I know their name, but creating a module and then applying using like this:
using PyPlot
a = Module(:Plots)
using a
will yield an excpetion telling me that a is not definied. Which is a very unintuitive error message, since when you do this on the repl you can use 'a' afterwards. Just in combination with using it tells you that it is not defined.
The error message is emitted by Base.require, so you should use using Main.a or using .a instead:
require(module::Symbol)
This function is part of the implementation of using / import, if a module is not already
defined in Main. It can also be called directly to force reloading a module, regardless of
whether it has been loaded before (for example, when interactively developing libraries).
...
When searching for files, require first looks for package code under Pkg.dir(), then tries paths
in the global array LOAD_PATH. require is case-sensitive on all platforms, including those with
case-insensitive filesystems like macOS and Windows.
Or just use module keyword to define a module on the fly:
module A
...
end
using A
For an existing module, you could also dynamically use it via eval(using module-name).
I've got a prices.js file with a ShoppingCartContents object that is defined in this file.
I'd like to access this ShoppingCartContents object inside my helpers.js file, where I will be using it to create a global helper.
I can easily do this by just setting ShoppingCartContents to global, but I don't want to do that. Is there a better way? According to the docs there's package scope and file scope. These two scopes don't seem granular enough to me (there's also a package export feature but I'm doing everything inside one package)
Things can only be scoped to:
one and only one file
the entire package
Shouldn't there be a file export feature maybe?
If you're working inside a package, make the variable global. That way you can access it in all your files, for your package.
If you want a truly global variable, you have to explicitly export it, so there's no problem in using globals.
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.