Jasming config flag (--config) does not use the right config file - node.js

I have my node server on path F:\proj\dev-react-node-java\src\server. I used 'jasmine init' to create spec folder here and running 'jasmine' in terminal runs the specs (tests) correctly.
I wish to run the tests from F:\proj\dev-react-node-java so I used the command
jasmine --config=src/server/spec/support/jasmine.json
at this path but I get the message 'No specs found'. Why is it not using the correct configuration file (jasmine.json)?
I am sure --config reaches for this file because:
Giving wrong path gives 'Cannot find module' error.
Writing errorful json also generates and error.
Here is the jasmine.json code for reference:
{
"spec_dir": "spec",
"spec_files": [
"**/*[sS]pec.js"
],
"helpers": [
"helpers/**/*.js"
],
"stopSpecOnExpectationFailure": false,
"random": true
}
spec/support/jasmine.json is the default path as far as I understand since running 'jasmine' command at path say F:\proj\dev-react-node-java\src\server\spec also results in No specs found.
jasmine version is 3.6.1
P.S. This is my first question asked here. Please inform if I made any mistakes in asking. Thank you.

I did find the reason. It is indeed not an issue with the config flag but rather with my jasmine.json file.
What I thought the use of config flag was to specify the path to the file instead of the default spec/support/jasmine.json. It would then have the same behaviour as if the relative path to config was spec/support/jasmine.json.
But
F:\proj\dev-react-node-java>jasmine --config=src/server/spec/support/jasmine.json
is not the same as
F:\proj\dev-react-node-java\src\server>jasmine --config=spec/support/jasmine.json
What it does instead is like copying it to the path from where the command was called and then using it to run the tests.
Hence, what worked was changing the spec_dir field.
{
"spec_dir": "src/server/spec",
"spec_files": [
"**/*[sS]pec.js"
],
"helpers": [
"helpers/**/*.js"
],
"stopSpecOnExpectationFailure": false,
"random": true
}
A little more clarification/examples in the docs would have been nicer but perhaps I misunderstood the functionality.

Related

Configure remark-lint-no-undefined-references plugin/rule 'Allow' option for remark-cli?

Original Question
How do I correctly "configure" the (unified, remark, remark-lint) remark-lint-no-undefined-references plugin/rule "allow" option for use with the remark-cli?
My goal is to configure the rule to ignore the Azure DevOps Wiki's non-standard table of contents tag, [[_TOC_]]. My simplified setup entails:
All packages globally installed. Probably not relevant.
A parent folder in which I have:
A package.json file.
A Test folder containing just the one Test.md file whose only content is this one line [[_TOC_]].
From a command prompt whose working folder is the aforementioned parent folder, I execute:
remark Test
Default Operation
The default operation, i.e. just the plugin/rule specified in the package.json file, returns the expected warning. This is, presumably, due to the non-standard tag, [[_TOC_]]. This is the warning I wish to turn off.
package.json (default)
{
"remarkConfig": {
"plugins": [
"remark-lint-no-undefined-references"
]
}
}
Execution and Expected Warning (default)
C:\..>remark Test
test\Test.md
1:1-1:10 warning Found reference to undefined definition no-undefined-references remark-lint
1:2-1:9 warning Found reference to undefined definition no-undefined-references remark-lint
‼ 2 warnings
What I've tried
I've tried to adapt remark-lint-no-undefined-references API example and Configuration, 'rules can be configured in one standard way' to my package.json file. After much trial and error, I've ended up with this seemingly valid json:
package.json
{
"remarkConfig": {
"plugins": [
"remark-lint-no-undefined-references", [1, {
"allow": ["[[_TOC_]]"]
}]
]
}
}
The Online JSON Viewer and JSONLint indicate it's valid JSON. However, remark-cli yields this error. Other variations yielded different errors. I am stumped.
C:\..>
Test\Test.md
1:1 error Error: Cannot parse file `package.json`
Expected preset, not `1`
at Error (file:///C:/Users/scott.welker/AppData/Roaming/npm/node_modules/remark-cli/node_modules/fault/index.js:39:12)
at file:///C:/Users/scott.welker/AppData/Roaming/npm/node_modules/remark-cli/node_modules/unified-engine/lib/find-up.js:190:15
at done (file:///C:/Users/scott.welker/AppData/Roaming/npm/node_modules/remark-cli/node_modules/trough/index.js:145:7)
× 1 error
Update 03/14/2022
I've made some progress thanks to a bit of help on GitHub Issue (#210). However, that was not the right avenue and it is closed. My issue remains.
A Few Things are Apparent
My initially inferred JSON, package.json, is incorrect. See Hacked my JSON below.
I failed to appreciate how the non-standard Azure DevOps Wiki table of contents tag, [[_TOC_]], is interpreted. See Tag Interpretation (console-log) following.
My inferred package.json seemingly remains incorrect. See My JSON Must Still be Wrong below.
Hacked my JSON
To overcome ...Error: Cannot parse file 'package.json', Expected preset, not '1' I hacked my file so that I now have the following. This change overcomes the error and enables me to continue but it is still seemingly incorrect. See My JSON Must Still be Wrong.
package.json file
{
"remarkConfig": {
"plugins": [
"remark-lint-no-undefined-references", {
"allow": ["_TOC_", "[_TOC_]"]
}
]
}
}
Tag Interpretation (console.log)
After hacking my JSON, I added a recommended console.log (..\npm\node_modules\remark-lint-no-undefined-references\index.js) of id. This reveals that the linting interprets the table of contents tag as two separate bits of concerning markdown, _TOC_ and [_TOC_]. I did not appreciate this. However, the findings below suggest this may not be a problem. See My JSON Must Still be Wrong.
remark-cli
C:\..>remark Test
Id: _TOC_
Id: [_TOC_]
Test\Test.md
1:1-1:10 warning Found reference to undefined definition no-undefined-references remark-lint
1:2-1:9 warning Found reference to undefined definition no-undefined-references remark-lint
‼ 2 warnings
My JSON Must Still be Wrong
Referring to another location in the source here (line 126), when I replace that const allow definition with this hard-coded declaration, const allow = new Set(["_TOC_", "[_TOC_]"]), I get the desired behavior. E.g.:
remark-cli
C:\...>remark Test
Test\Test.md: no issues found
Next Steps:
See whether I can forgo the package.json and instead use pure javascript. Either my JSON is incorrect or it isn't being interpreted correctly.
Continue to futz with the JSON. What I've inferred may well be wrong.
The following guess also fails to suppress the unwanted warnings:
package.json
{
"remarkConfig": {
"plugins": [
"remark-lint-no-undefined-references", [{
"allow": ["_TOC_", "[_TOC_]"]
}]
]
}
}
Update 03/28/2022
CAUTION!
While the setup in this update is valid, the Test.js example code is flawed. See 03/30/2022 Update below.
Following up on "Next Step, see whether I can forgo the package.json and instead use pure javascript."
I seem to have made it work except it suppresses all warnings, not just the few (two) that I am targeting. More development and testing is needed.
New Setup
A new parent Node.js application folder in which I have:
Opted to re-install all packages, and some new ones, but not globally (this time):
npm install to-vfile
npm install vfile-reporter
npm install remark
npm install remark-lint
npm install remark-lint-no-undefined-references
The node_modules folder. Created and populated by npm installs (dependencies).
A package.json file. Created and populated by npm installs.
A package-lock.json file. Created and populated by npm installs.
A copy of the same Test folder containing just the one Test.md file whose only content is this one line [[_TOC_]].
From a command prompt whose working folder is the aforementioned parent folder, I execute my new node/javascript code:
node Test.js See following. Code comments illustrate the unexpected suppression of all warnings, even those not targeted.
Test.js
WARNING! This code is incorrect. See the 03/30/2022 Update below.
import {reporter} from 'vfile-reporter'
import {remark} from 'remark'
import remarkLint from 'remark-lint'
import remarkLintNoUndefinedReferences from 'remark-lint-no-undefined-references'
import {read} from 'to-vfile'
main()
async function main() {
const file = await remark()
.use(remarkLint)
// This useage results in the expected warnings, '...Found reference to undefined definition...'
.use(remarkLintNoUndefinedReferences)
// This usage suppresses the warnings, as desired. However, note the next usage.
//.use(remarkLintNoUndefinedReferences[ { allow: [ '_TOC_', '[_TOC_]' ] }])
// This usage also suppresses the warning but it shoud not have done so.
//.use(remarkLintNoUndefinedReferences[ { allow: [ '...', '…' ] }])
// This usage (and related tests) seem to illustrate that anything in the allowed array suppresses all warnings.
//.use(remarkLintNoUndefinedReferences[ { allow: [ '' ] }])
.process(await read('.\\Test\\Test.md'))
console.error(reporter(file))
}
Update 03/30/2022
Here is a corrected Test.js file where my invalid usages are commented out, marked WRONG, and the two correct usages are marked GOOD. The final usage corrects mistakes made in my 03/28/2022 update. I now have a working javascript version. I just need to adapt this known working version to the remark-cli's package.json file. Getting very close.
I arrived at this CORRECT, working usage through trial and error. My trial and error was aided by adding console.log() statements to the ..\remark-lint-no-undefined-references\index.js source and tweaking my javascript code as guided by repeated re-reading of the remark-lint Configure section.
Test.js
import {reporter} from 'vfile-reporter'
import {remark} from 'remark'
import remarkLint from 'remark-lint'
import remarkLintNoUndefinedReferences from 'remark-lint-no-undefined-references'
import {read} from 'to-vfile'
main()
async function main() {
const file = await remark()
.use(remarkLint)
// WRONG: This usage seems to suppress the warnings, as desired. However, note the next usage.
//.use(remarkLintNoUndefinedReferences[ { allow: [ '_TOC_', '[_TOC_]' ] }])
// WRONG: This usage also seems to supresses the warnings but, it shoud not have done so.
//.use(remarkLintNoUndefinedReferences[ { allow: [ '...', '…' ] }])
// WRONG: This usage (and related tests) seem to illustrate that anything in the allowed array suppresses all warnings.
//.use(remarkLintNoUndefinedReferences[ { allow: [ '' ] }])
// GOOD: This usage results in the expected warnings, '...Found reference to undefined definition...'
//.use(remarkLintNoUndefinedReferences)
// GOOD: This usage seems to be correct!!
.use(remarkLintNoUndefinedReferences, [1, { allow: [ '_TOC_', '[_TOC_]' ] }])
.process(await read('.\\Test\\Test.md'))
console.error(reporter(file))
}
Execution and Output
C:\..>node Test.js
DEBUG remarkTest: allow contains 2 items.
DEBUG remarkTest Id: '_TOC_'
DEBUG remarkTest Id: '[_TOC_]'
.\Test\Test.md: no issues found
The package.json below correctly "configures" the remark-lint-no-undefined-references plugin/rule "allow" option for use with remark-cli.
Note: I also transitioned away from globally installed packages out of an unsubstantiated concern that they might have contributed to my problem. See Multiple globally installed presets and plugins don’t work #165. This transition accounts for the added package.json "dependencies". See following.
package.json
I arrived at this by working from my 03/30/2022 update and futzing with varying syntax illustrated in the Unified Engine, Configuration, Schema section.
Again, my goal is to configure the rule to ignore the Azure DevOps Wiki's non-standard table of contents tag, [[_TOC_]].
{
"remarkConfig": {
"plugins": {
"remark-lint-no-undefined-references": { "allow":[ "_TOC_", "[_TOC_]" ] }
}
},
"dependencies": {
"remark": "^14.0.2",
"remark-lint": "^9.1.1",
"remark-lint-no-undefined-references": "^4.1.1"
}
}
Execution and Output
Note: my debug console.log(...) remains in place.
C:\..>remark Test
DEBUG remarkCLITest: allow contains 2 items.
Test\Test.md: no issues found

Jest "Cannot find module" with typescript paths in CI

On the Gitlab-CI environment 2 of our Jest tests fail with Cannot find module.
The strange thing is that it works on my local Win10 machine - even when I run the tests in a similar docker-container (node 12.12.0).
Here is the console output:
FAIL apps/server/src/domain/dashboard/permission-group.service.spec.ts
Test suite failed to run
Cannot find module '#cm/utils-server' from 'license.service.ts'
9 | isLicenseFileContent,
10 | LicenseStatus,
> 11 | parseLicenseInfo
| ^
12 | } from '#cm/license-shared';
13 | import { ExitCode } from '../../util/exit-codes';
14 | import { readFile } from '#cm/utils-server';
at Resolver.resolveModule (../../node_modules/jest-resolve/build/index.js:259:17)
at Object.<anonymous> (src/domain/license/license.service.ts:11:24)
I am not sure how to correctly interpret this output:
permission-group.service.spec.ts: this is the test that fails
Cannot find module '#cm/utils-server' from 'license.service.ts':
Ok, the test or some of its dependencies, use license.service.ts and in the license.service.ts file the '#cm/utils-server' module cannot be found.
What is the meaning of error-indicator (> at parseLicenseInfo)?
This is for the import #cm/license-shared - not for #cm/utils-server as indicated by the error message in 2
#cm/utils-server is also imported, but 2 lines below in line 14: So is this maybe just a bug in jest?
I just had this issue and searched for some solutions. Found this site which gave a clue about what could be done: to configure Jest's moduleNameMapper property.
So, reading the documentation I found this solution:
Open the tsconfig.json and jest.config.js files (or equivalent)
In tsconfig.json, find your absolute paths definition. My configuration looks like this:
"paths": {
"#modules/*": ["modules/*"],
"#config/*": ["config/*"],
"#shared/*": ["shared/*"]
}
In the jest.config.json, find and uncomment the moduleNameMapper property and start to translate your TS absolute paths into the Jest mapper syntax. Sounds complicated, but it isn't:
moduleNameMapper: {
"#modules/(.*)": "<rootDir>/src/modules/$1",
"#config/(.*)": "<rootDir>/src/config/$1",
"#shared/(.*)": "<rootDir>/src/shared/$1",
}
The <rootDir> if defined automatically, and points to the package.json directory
"#modules/(.*)" is a Regex for "any string starting with '#module/' followed by anything after it
"<rootDir>/src/modules/$1" is the corresponding directory. $1 is a pointer to the Regex expression between the parenthesis ((.*)). Other expressions will be pointed by $2, $3 and so on
After doing this, I was able to execute my tests without any problem.
Console output before follow the above steps:
$ jest
FAIL src/modules/appointments/services/CreateAppointmentService.spec.ts
● Test suite failed to run
Cannot find module '...'
Console output after:
$ jest
PASS src/modules/appointments/services/CreateAppointmentService.spec.ts
Hope this help someone,
Thanks!
For those who are facing this issue in 2022. Please add this code in your
jest-unit.json (or your jest config json file).
"moduleDirectories": ["<rootDir>/../", "node_modules"]
Result:
{
"moduleFileExtensions": ["js", "json", "ts"],
"rootDir": ".",
"testEnvironment": "node",
"testRegex": ".\\.spec.ts$",
"transform": {
"^.+\\.(t|j)s$": "ts-jest"
},
"moduleDirectories": ["<rootDir>/../", "node_modules"]
}
For now we use a workaround: we had paths defined in multiple tsconfig.json files of our mono-repo. We moved all paths up to the root-tsconfig and now the tests work again.
But we don't really understand why this works.
And a drawback is that it's now easy to accidentally refer to a path that you shouldn't use in the lib (because the IDE now always uses all paths for code-assistance)
I meet the same problem, I found the reason is the package(which cannot found) doesn't set the main field in package.json, add it then everythings ok.

Trying to share code from Hyperapp with Bit.dev

I'm trying to share my code from my front (hyperapp) to my admin (hyperapp to) to make "preview" button.
The setup of these projects was made by an other dev, so i had to learn hyperapp workflow on the job, i'm not expert.
From what i know he was inspired by Facebook React conf.
All my usefull code is in src/ folder, and there is many dependencies so i have to export all (api, constants, utils, etc..).
Here is my bit configuration (that work, it export code correctly):
"bit": {
"env": {
"compiler": "bit.envs/compilers/react#1.0.2"
},
"packageManager": "yarn",
"packageManagerArgs": [
"--production",
"--no-optional"
],
"packageManagerProcessOptions": {
"shell": true
},
"resolveModules": {
"modulesDirectories": [
"src"
]
},
"dist": {
"entry": "src",
"target": "dist"
}
}
So, the code is "correctly" exported to bit.dev, but, when i import it from my admin with
"#bit/adrienbelair.betterise-web.modules": "^0.3.0",
i get the following error after running yarn:
yarn install
ls: Command failed.
Exit code: 1
Command: node .bit.postinstall.js
...
Error: ENOTDIR: not a directory, mkdir 'node_modules/utils/HOA'
Yes, if i look into node_module, utils is a file, and not a directory
All these are auto-generated, i dont understand what am i doing wrong?
Second thing, probably from this above error, when i try to import a component (even if there is an error, vendor are downloaded and at their place), i get:
import { Advice } from '#bit/adrienbelair.betterise-web.modules/dist/modules';
./node_modules/#bit/adrienbelair.betterise-web.api/controlleur.js
Module not found: Can't resolve 'api' in '/Users/prinzivalle/Web/betterise/admin-front/node_modules/#bit/adrienbelair.betterise-web.api'
From this line (if i look into node_module, where the error is thrown):
import { User, Cardline } from 'api';
I know, its a very specific case, mine, but i dont find any forum or explicit tutorial. Only some little component export with not a lot of dependencies.
I made my code with a little knowledge of Hyperapp/React and without thinking about sharing it one day..
Thank for reading.

Errors with relative paths in using Chutzpah and Require.js

I'm using Chutzpah, with Jasmine, to unit test a number of AMD modules using Require.js.
My unit test project is separate to both the modules under test and the require.js config file.
I'm using chutzpah.json to connect these together, as such:
{
"Framework": "jasmine",
"TestHarnessReferenceMode": "AMD",
"TestHarnessLocationMode": "SettingsFileAdjacent",
"EnableTestFileBatching": true,
"AMDBasePath": "matches baseUrl path in require.js config file",
"References" : [
{"Path" : "path to require.js" },
{ "Path": "path to require.js config file" }
],
"Tests" : [
{"Path": "Specs"}
]
}
The tests run okay as expected.
The issue is that somewhere in the magic of resolving dependencies, I'm getting errors that a number of the css files cannot be located. These are relative paths and I'm guessing that because I'm initiating the test from a separate project it cannot correctly identify the base path.
As I say this isn't an issue running tests locally, but would cause an issue when integrating with a CI build.
Has anybody experienced this before and know of a workaround?

jshint and sublimelinter settings config on mac

I'm trying to configure sublimelinter, specifically jshint on my Mac. On my windows version of SublimeText there is the following section in SublimeLinter.sublime-settings
"jshint_options":
{
// To fix column positions for JSHint errors you may want to add `"indent": 1` to your
// **User** "jshint_options". This issue affects users with tabs for indentation.
// This fix was reverted due to a conflict with using the `"white": true` option.
// "indent": 1,
"evil": true,
"regexdash": true,
"browser": true,
"wsh": true,
"trailing": true,
"sub": true
},
When I view the file on my Mac this section doesn't exist, is there a place to edit these option on the Mac version without a separate settings file? Or a global settings file for jshint?
I've been digging through similar questions but haven't found a clear solution.
Update:
Actually it doesn't seem to catch any errors at all when using it on the console. My javascript file doesn't end in .js how can I configure it to look at different extensions? I can't find it in the docs.
There's another way to set options globally, without using ".jshintrc" files.
1) create a file with any name (e.g. "jshint.conf"). my file is:
{
"globals": { "$": false },
"globalstrict": true,
"devel": true
}
2) put it anywhere. in my case it is: "c:\Users\Smith\AppData\Roaming\Sublime Text 3\Packages\User\"
3) make the next reference in section "jshint"->"args" of sublime-linter user setting (user/SublimeLinter.sublime-settings):
{
"user": {
"linters": {
"jshint": {
"args": [
"--config", "c:\\Users\\Smith\\AppData\\Roaming\\Sublime Text 3\\Packages\\User\\jshint.conf"
]
}
}
}
}
4) Enjoy!
In general I would recommend against configuring JSHint system-wide. It's usually safer to create a .jshintrc file for each project your work on because it's likely they will have different JSHint requirements.
The jshint_options SublimeLinter setting you mention in your question is from the old version of SublimeLinter, which has recently been reworked to have a simple plugin architecture. The JSHint plugin (which I assume you are using, since the settings you tried didn't work) makes the same recommendation:
You can configure jshint options in the way you would from the command line, with .jshintrc files.
The added benefit of this approach is that you can commit the .jshintrc file to your repository and ensure that anyone who works on the project is working with the same JSHint rules, rather than their own system-wide settings.

Resources