I want to be able to modify the waitTimeout setting for RequireJS when used within an Aurelia CLI project.
Is there a standard way to modify RequireJS config in this context? Can it be done from aurelia.json directly, or a prepend script, for example?
You can add config to the aurelia.json file, see the section in the Aurelia docs here http://aurelia.io/hub#/doc/article/aurelia/framework/latest/the-aurelia-cli/11
Add a build.loader.config.waitSeconds key/value.
The exact example from the docs:
"build": {
"loader": {
"type": "require",
"configTarget": "vendor-bundle.js",
"includeBundleMetadataInConfig": "auto",
"config": {
"waitSeconds": 60
}
}
}
Related
I have a (demo) application hosted on Heroku. I've enabled Heroku's "review app" feature to spin up new instances for pull request reviews. These review instances all get a new MongoDB (on mLab) provisioned for them through Heroku's add-on system. This works great.
In my repository, I've defined some seeder scripts to quickly get a test database up and running. Running yarn seed (or npm run seed) will fill the database with test data. This works great during development, and it would be perfect for review apps as well. I want to execute the seeder command in the postdeploy hook of the Heroku review app, which can be done by specifying it under the environment.review section of the app.json file. Like so:
{
"name": "...",
"addons": [
"mongolab:sandbox"
],
"environments": {
"review": {
"addons": [
"mongolab"
],
"scripts": {
"postdeploy": "npm run seed"
}
}
}
}
The problem is, the seeder script relies on some development-only dependencies (faker, ts-node [this is a TypeScript project], and mongo-seeding) to execute. And these dependencies are not available in the postdeploy phase of an Heroku app.
I also don't think that "compiling" the typescript in the regular build step is the best idea. This seeder script is only used in development (and review apps). Besides, I'm not sure that would resolve the issue with missing dependencies like faker.
How would one go about this? Any tricks I'm missing?
Can I maybe skip Heroku's step where it actively deletes development dependencies? But only for review apps? Or even better, can I "exclude" just the couple of dependencies I need, and only for review apps?
The Heroku docs indicate that when the NODE_ENV variable contains anything but "production", the devDependencies will not be removed after the build step.
To make sure this only happens for Heroku review apps, you can set the NODE_ENV variable under the environments.review section of the app.json file. The following config should do the trick:
{
"name": "...",
"addons": [
"mongolab"
],
"environments": {
"review": {
"addons": [
"mongolab:sandbox"
],
"env": {
"NODE_ENV": "development"
},
"scripts": {
"postdeploy": "npm run seed"
}
}
}
}
With a node.js project, I've added eslint-plugin-security and it is giving a lot of warnings for code in my test/spec files (using mochajs). Since the test code won't be running in production, these don't seem as useful as they do in the project's actual code. (A lot of Generic Object Injection Sink warnings )
Is there a way to have the security plugin ignore certain files other than putting /* eslint-disable */ at the top of every spec file?
The best way I found to deal with this case is based on this answer.
You can override parts of your eslint file in a subfolder. In my case I'm disabling problematic rules from a jest plugin inside my e2e tests folder. Example .eslintrc.js in /e2e-tests/ :
module.exports = {
overrides: [
{
files: ["*.spec.js"],
rules: {
"jest/valid-expect": 0
}
}
]
};
There is three way to ignore files or folders:
1. Creating a .eslintignore on your project root folder with the thing you want to ignore:
**/*.js
2. Using eslint cli & the --ignore-path to specify another file where your ignore rules will be located
eslint --ignore-path .jshintignore file.js
3. Using your package.json
{
"name": "mypackage",
"version": "0.0.1",
"eslintConfig": {
"env": {
"browser": true,
"node": true
}
},
"eslintIgnore": ["*.spec.ts", "world.js"]
}
Official Documentation
On my side, I had issue with Intellij IDEA where eslint was checking files in a folder only dedicated to Typescript (+tslint) which was a pain, so I've picked solution 3.
Can someone give an example on how to use jest globals?
{
...
"jest": {
"globals": {
"__DEV__": true,
}
}
...
}
Do I specify the globals in the package.json file or do I create a folder with a js file where the globals should be defined?
Thanks
Yep. You put the globals in the package.json. For example, here's an excerpt from the default react-native jest configuration:
"jest": {
"globals": {
"__DEV__": true,
"__RCTProfileIsProfiling": false
},
...
},
This will make the variables available globally when the tests are run.
A cleaner way to add globals would be to set "setupFiles": "<rootDir>/private/jest/setup.js" in package.json, and then create a setup.js file that sets global.__DEV__ = true.
This pattern is helpful for making 3rd party libraries available as globals to Jest tests as well (like Backbone, jQuery, lodash, etc.) - eg. global.Backbone = require('backbone'); and so on.
(Re-submitting this as an answer as it was previously just a comment under Michael Helvey's answer.)
For me using the Jest config file worked much better because it is a Javascript file itself so it gives full freedom:
After running jest --init in your folder, in the jest.config.js file Jest makes, scroll down to find:
// A set of global variables that need to be available in all test environments
// globals: {},
Uncomment the second line and put all your globals in there.
If you are using create-react-app, you must use the src/setupTests.js file instead of pointing to a file via setupFiles in the package.json file.
https://create-react-app.dev/docs/running-tests/#srcsetuptestsjs
In the src/setupTests.js file, you can define globals like so:
global.TIMEOUT = 3000;
To share object variables (not only primitives as with configuration's globals property), you can use the testEnvironment property.
More explanations here in Jest's Git
In my project, I'm using Babel 6 with the require hook. I need to load a custom babel plugin that I wrote. But do I really need to publish my plugin using npm first, and then include the plugin name in my main project's .babelrc?
Is there any way to just directly load the plugin code? In other words, can I just load the following directly?
export default function({types: t }) {
return {
visitor: {
...
}
};
}
Where you list your plugins in your .babelrc, provide the path to your plugin instead of your standard published plugin name.
"plugins": ["transform-react-jsx", "./your/plugin/location"]
When exporting your plugin function, you'll probably need to use module.exports = instead of export default, since ES2015 modules haven't been fully implemented in Node yet.
This is my entire babel.config.js file.
module.exports = function (api) {
api.cache(true);
const presets = ["#babel/preset-env", "#babel/preset-react"];
const plugins = [
["#babel/plugin-proposal-pipeline-operator", { "proposal": "minimal" }],
"c:\\projects\\my-babel-plugin"
];
return {
presets,
plugins
};
}
First item in the plugins array is a plugin with options in form of an array. Second item is my own local plugin.
Inside of my-babel-plugin folder there needs to be a package.json with the "main" entry, usually "main": "lib/index.js" or "main": "src/index.js".
I am assigning a property to the global window object, but when I run eslint, I get this:
"window" is not defined
I see this here in the eslint docs:
the following defines window as a global variable for code that should not trigger the rule being tested:
valid: [
{
code: "window.alert()",
globals: [ "window" ]
}
]
I've tried adding something like this to the package.json file to have eslint allow "window" as a global variable, but I must be doing something wrong. From the docs it seems like I might need to do something like this in a separate file, but is there a way to define some allowed global variables right in the package.json file?
There is a builtin environment: browser that includes window.
Example .eslintrc.json:
"env": {
"browser": true,
"node": true,
"jasmine": true
},
More information: https://eslint.org/docs/user-guide/configuring/language-options#specifying-environments
Also see the package.json answer by chevin99 below.
I found it on this page: http://eslint.org/docs/user-guide/configuring
In package.json, this works:
"eslintConfig": {
"globals": {
"window": true
}
}
Add .eslintrc in the project root.
{
"globals": {
"document": true,
"foo": true,
"window": true
}
}
Your .eslintrc.json should contain the text below.
This way ESLint knows about your global variables.
{
"env": {
"browser": true,
"node": true
}
}
I'm aware he's not asking for the inline version. But since this question has almost 100k visits and I fell here looking for that, I'll leave it here for the next fellow coder:
Make sure ESLint is not run with the --no-inline-config flag (if this doesn't sound familiar, you're likely good to go). Then, write this in your code file (for clarity and convention, it's written on top of the file but it'll work anywhere):
/* eslint-env browser */
This tells ESLint that your working environment is a browser, so now it knows what things are available in a browser and adapts accordingly.
There are plenty of environments, and you can declare more than one at the same time, for example, in-line:
/* eslint-env browser, node */
If you are almost always using particular environments, it's best to set it in your ESLint's config file and forget about it.
From their docs:
An environment defines global variables that are predefined. The
available environments are:
browser - browser global variables.
node - Node.js global variables and Node.js scoping.
commonjs - CommonJS global variables and CommonJS scoping (use this for browser-only code that uses Browserify/WebPack).
shared-node-browser - Globals common to both Node and Browser.
[...]
Besides environments, you can make it ignore anything you want. If it warns you about using console.log() but you don't want to be warned about it, just inline:
/* eslint-disable no-console */
You can see the list of all rules, including recommended rules to have for best coding practices.
If you are using Angular you can get it off with:
"env": {
"browser": true,
"node": true
},
"rules" : {
"angular/window-service": 0
}