I'm using the speech-rule-engine to generate English text from MathML. When trying to upgrade from v3.1.1 to v3.2.0 I'm seeing tests fail for reasons I don't understand.
I created a simple two file project that illustrates the issue:
package.json
{
"name": "failure-example",
"license": "UNLICENSED",
"private": true,
"engines": {
"node": "14.15.5",
"npm": "6.14.11"
},
"scripts": {
"test": "jest"
},
"dependencies": {
"speech-rule-engine": "3.2.0"
},
"devDependencies": {
"jest": "^26.6.3"
},
"jest": {
"notify": false,
"silent": true,
"verbose": true
}
}
example.test.js
const sre = require('speech-rule-engine');
beforeAll(() => {
sre.setupEngine({
domain: 'mathspeak'
});
});
test('simple single math', () => {
expect(JSON.parse(JSON.stringify(sre.engineSetup(), ['domain', 'locale', 'speech', 'style'])))
.toEqual({
locale: 'en',
speech: 'none',
style: 'default',
domain: 'mathspeak',
});
expect(sre.engineReady())
.toBeTruthy();
expect(sre.toSpeech('<math><mrow><msup><mn>3</mn><mn>7</mn></msup></mrow></math>'))
.toBe('3 Superscript 7');
});
Running npm install and npm run test results in a failure because SRE is returning 37 instead of 3 Superscript 7. Editing package.json to use v3.1.1 of the engine and rerunning results in a passing test.
Obviously something has changed, but I'm totally missing what I need to do to adapt. Has anyone else encountered this, or see what I clearly do not?
Problem solved, with the help of the maintainer of SRE. The problem is not in 3.2.0, but that jest does not wait for sre to be ready. The test was only correct by a fluke in 3.1.1 as the rules were compiled into the core. The following test fails with the above setup in 3.1.1 as well as the locale is not loaded:
expect(sre.toSpeech('<math><mo>=</mo></math>'))
.toBe('equals');
Expected: "equals"
Received: "="
The main reason is that jest fails to load the locale file. Setting "silent": false will show the error:
Unable to load file: /tmp/tests/node_modules/speech-rule-engine/lib/mathmaps/en.js
TypeError: Cannot read property 'readFileSync' of null
The reason for this error is that jest does not know that it runs in node. Adding:
"testEnvironment": "node",
to the jest configuration in package.json causes the expected behavior.
Related
Trying to get a sitemap made for my Next JS site using next-sitemap. From my research, next-sitemap doesn't work on Windows without including cross-env. Any suggestions on what to do?
I currently have my postbuild command set to:
"postbuild": "cross-env next-sitemap --config next-sitemap.js""postbuild": "cross-env next-sitemap --config next-sitemap.js"
And here is my next-sitemap.js:
let policy = {
userAgent: "*",
};
if (process.env.ENVIRONMENT !== "production") {
policy.disallow="/";
};
module.exports = {
siteUrl: process.env.URL,
generateRobotsTxt: true,
robotsTxtOptions: {
policies: [
policy
],
},
outDir: "./out"
}
Tryp running npm run build (or yarn build) first, on this youtube video happened the same to him and he did it like that:
https://www.youtube.com/watch?v=zS-6oiwvNnc
I don't think you need the cross-env, but for windows what you have to do is changing the file name instead. See the docs here.
I'm using Jest to run unit tests on one of my components, but I'm getting a few errors.
The component that I am trying to test uses tinymce and as a result, I import a few files from tinymce. I've seen on the offical Jest documentation that I insert the following, which I have in my setupTests.js file:
Object.defineProperty(window, 'matchMedia', {
writable: true,
value: jest.fn().mockImplementation(query => ({
matches: false,
media: query,
onchange: null,
addListener: jest.fn(), // Deprecated
removeListener: jest.fn(), // Deprecated
addEventListener: jest.fn(),
removeEventListener: jest.fn(),
dispatchEvent: jest.fn(),
})),
});
However, I have done that, but I am encountering another problem:
Jest encountered an unexpected token SyntaxError: Unexpected token '.'
import "tinymce/skins/ui/oxide.skin.min.css"
I have tried to follow the advice of mocking everything that comes from Tinymce, as well as mocking non-JS modules, using "moduleNameMapper". For example, my _jest.config.js file includes:
module.exports = {
"moduleNameMapper": {
"^image![a-zA-Z0-9$_-]+$": "GlobalImageStub",
"^[./a-zA-Z0-9$_-]+\\.png$": "<rootDir>/RelativeImageStub.js",
"module_name_(.*)": "<rootDir>/substituted_module_$1.js",
"assets/(.*)": [
"<rootDir>/images/$1",
"<rootDir>/photos/$1",
"<rootDir>/recipes/$1"
]
}
"transformIgnorePatterns": [
"<rootDir>/node_modules/"
]
}
The above doesn't work and I still get the same error.
EDIT:
As per one of the suggestions, I've created a styleMock.js file which contains module.exports = {}; and is included in my src/tests/jest/__mocks__ path. I've then inputted:
"moduleNameMapper": {
'\\.(css|less)$': '<rootDir>/src/tests/jest/__mocks__/styleMock.js'
}
But I'm still getting the same error as above.
Following this documentation worked.
In another words, adding in the package.json the following:
{
"jest": {
"moduleNameMapper": {
"\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$": "<rootDir>/__mocks__/fileMock.js",
"\\.(css|less)$": "identity-obj-proxy"
}
}
}
As well as running yarn add --dev identity-obj-proxy
I created a cloud function project with firebase a few months ago, and used linting.
I recently created a new cloud function project with linting, and now the linter is complaining about random rules I never set. I don't remember it enforcing nearly the amount of style rules a few months ago.
Things like:
This line has a length of 95. Maximum allowed is 80
Missing JSDoc comment
Missing Trailing comma
expected indentation of 2 spaces but found 4
Strings must use singlequote
It's also not letting me use async/await.
I found out I can individually set these rules in my .eslintrc.js file, but that's annoying and I don't want to do that. By default, why aren't these rules disabled? I just want basic rules that make sure my code won't fail when run, not random style preferences like single/double quotes and max line length.
Is there any way to use just basic linting functionality with firebase functions?
I ran into the same issue as you. The new, more strict linting rules seem to come from the fact that Firebase functions use the "google" eslint base configuration plugin by default now. Read more about configuring ESLint plugins in the docs. My older Firebase functions were using tslint without issue.
Here's what my .eslintrc.js file looked like while I was getting style errors from eslint:
module.exports = {
env: {
es6: true,
node: true,
},
extends: [
'eslint:recommended',
'plugin:import/errors',
'plugin:import/warnings',
'plugin:import/typescript',
'google',
],
parser: '#typescript-eslint/parser',
parserOptions: {
project: ['tsconfig.json', 'tsconfig.dev.json'],
sourceType: 'module',
},
ignorePatterns: [
'/lib/**/*', // Ignore built files.
],
plugins: ['#typescript-eslint', 'import'],
rules: {
quotes: ['error', 'double'],
},
};
I deleted 'google' from the extends property, which seemed to resolve almost all of the style linting issues.
Now it looks like this:
module.exports = {
env: {
es6: true,
node: true,
},
extends: [
'eslint:recommended',
'plugin:import/errors',
'plugin:import/warnings',
'plugin:import/typescript',
],
parser: '#typescript-eslint/parser',
parserOptions: {
project: ['tsconfig.json', 'tsconfig.dev.json'],
sourceType: 'module',
},
ignorePatterns: [
'/lib/**/*', // Ignore built files.
],
plugins: ['#typescript-eslint', 'import'],
rules: {
quotes: ['error', 'double'],
},
};
You can get rid of the google extends value but I would suggest keeping it and just turning off the rules that bother you the most, which for me is indentation and max length (of lines):
module.exports = {
root: true,
env: {
es6: true,
node: true,
},
extends: [
"eslint:recommended",
"google",
],
rules: {
"quotes": ["error", "double"],
"indent": ["off"],
"max-len": ["off"],
},
};
For anyone who is confused by this, there is a lint config file in the Cloud Functions folder that you can edit. As of this answer, that file is named .eslintrc.js.
I'm getting
You are currently using minified code outside of NODE_ENV === 'production'. This means that you are running a slower development build of Redux. You can use loose-envify (https://github.com/zertosh/loose-envify) for browserify or DefinePlugin for webpack (http://stackoverflow.com/questions/30030031) to ensure you have the correct code for your production build.
I tried to fix it by adding following codes to my webpack config. But it didn't work for Redux. However, following codes did fix a similar warning from React.
plugins: [
...
new webpack.DefinePlugin({
'process.env': {
'NODE_ENV': '"production"'
}
}),
...
Did I miss anything?
Got it work after some trial and error
plugins: [
new webpack.DefinePlugin({
'process.env': {
'NODE_ENV': '"production"'
}
})
]
Then in my package.json I run npm script "build:webpack" which does the following
"build:webpack": "webpack -p --define process.env.NODE_ENV='\"production\"'"
I am using webpack.DefinePlugin to inject global constants as part of my build pipeline. jshint however complains that the constant "is not defined".
From my webpack.config.js:
plugins: [
new webpack.DefinePlugin({
__ALEX__: JSON.stringify('alex.com')
}),
leads to:
WARNING in ./src/Main.js
jshint results in errors
'__ALEX__' is not defined. # line 12 char 30
lock: new Thing(__ALEX__)
What is the correct way to have jshint look at the code after the constants are injected?
Add the following to .eslintrc
{
"globals": {
"__ALEX__": true
},
"parser": "babel-eslint",
"parserOptions": {
"sourceType": "module",
"allowImportExportEverywhere": true
}
}
Without adding the parser and parsterOptions fields, I get weird pre ECMA Script 16 errors.