I have a function that looks like this:
export const maybeDate = R.unless(R.isNil, R.constructN(1, Date));
Typescript never gives me a hard time about this, but the moment I run it through Jest, I get this message with zero feedback on what is going on wrong:
TypeError: R.unless is not a function
It stops giving me problems the moment I change it to the following:
export const maybeDate = () => R.unless(R.isNil, R.constructN(1, Date));
However my app itself stops working.
Back in ramda's github, I was suggested to do
export const maybeDate = (v) => R.unless(R.isNil, R.constructN(1, Date))(v);
But this feels more of a workaround (as much as my crappy non-working solution was) than a solution.
What's the best way to fix this?
Currently all I have installed is this:
"ramda": "^0.27.1"
As you can see, Ramda 0.27.1 has the unless method.
const isEven = (n) => n % 2 === 0;
const shoutOdds = R.unless(isEven, console.log.bind(null, 'this "%s" looks odd'));
shoutOdds(5);
shoutOdds(10); // not called
shoutOdds(7);
<script src="https://cdnjs.cloudflare.com/ajax/libs/ramda/0.27.1/ramda.js" integrity="sha512-3sdB9mAxNh2MIo6YkY05uY1qjkywAlDfCf5u1cSotv6k9CZUSyHVf4BJSpTYgla+YHLaHG8LUpqV7MHctlYzlw==" crossorigin="anonymous" referrerpolicy="no-referrer"></script>
if you use es modules,
please make sure to import the ramda's namespace this way: import * as R from 'ramda'
Related
I'm learning Node.js and am using a Node-based Azure Function.
I'm trying to bring in Chalk, to log coloured messages to the console.
However, all of the below fail (in my main index.js file).
One
module.exports = async (ctx, req) => {
const chalk = require('chalk');
return console.log(chalk.blue('Hello world!'));
Despite being the approach recommended in this answer, this results in a console error that says:
Exception: require() of ES Module C:...\node_modules\chalk\source\index.js from C:...\index.js not supported.
Instead change the require of C:...\chalk\source\index.js in C:...\index.js to a dynamic import() which is available in all CommonJS modules.
Two
If I do as the error suggests, and use
const chalk = async import('chalk')
...I then get
Exception: chalk.blue is not a function
...even though console.log(chalk) does seem to show the Chalk API and its various properties.
Three
The Chalk docs themselves recommend this:
module.exports = async (ctx, req) => {
import chalk from 'chalk'
return console.log(chalk.blue('Hello world!'));
That yields an error saying I can't use import outside of a module (but surely I'm in one?)
Four
Same as three ^^ but moving the import outside module.exports:
import chalk from 'chalk'
module.exports = async (ctx, req) => {
return console.log(chalk.blue('Hello world!'));
...yields the same error.
I'm sure this is a basic error but I can't find what I'm doing wrong so I'd be so grateful if someone could help. Thank you!
When you import something using import as a function(lazy import), It'll return an object with a default property and all exported properties. That you should use to access the module.
const module = async import('chalk')
const chalk = module.default
console.log(chalk.red('Hello world!'))
I have a JS file code.js that will be loaded with a website containing code like the following:
window.someObject = window.someObject || {};
window.someObject.someFunction= function(aCondition) {
if (aCondition) someExternalObject.someFunc2();
};
setTimeout(window.someObject.someFunction, 1000);
I can't change this code.
I want to write a unit test for this, so my test file would look something like this:
const expect = require('chai').expect;
var rewire = require('rewire');
var codeModule = require('./path/to/file/code.js');
describe('Test code.js', () => { //Using Mocha.js
//Stub someObject.someFunction
//Test stub with expect()
})
//MORE CODE
This results in ReferenceError: window is not defined since there is no window object in Node.
The reason I'd want to import that module is that I'd want to mock someObject.someFunction for my test.
How can I deal with references to browser APIs like the window object when testing with Node?
Do I need to require a package like this before?
I'm pretty new to this so bear with me if I have some misconceptions here.
Before you import the file do this.
window = window || {}
It will define the window object in the global namespace, but of course with none of the good stuff you get in a browser.
I've seen that issue a lot here but none of the solutions worked for me. I'm using NodeJS and had no issue until I changed the project's directory.
Since then I can't get my code to work...
I've included:
import "#babel/polyfill"
I'm using async / await and this is clearly what's causing the issue:
async function process_data(post) {
// my_code
}
If I write the code like that:
const test = async function process_data(post) {
// my code
}
That's working but I can no longer call the process_data method on its own with the parameter (or else, I don't know how do it).
Any idea how I can get that to work?
By tweaking the code I found the answer:
const my_func = async function process_data(post) {
// my code
}
var res = my_func(post_var);
Can anybody help me please. How can i use moment in a formatter?
i think this is not a problem from node or binary parser. it is my understanding i think.
const Parser = require("binary-parser").Parser;
const moment = require('moment');
let time = function(timestamp) {
return moment(timestamp, 'YYMMDDHHmmssSS').format('YYYY-MM-DD HH:mm:ss.SS');
};
let Telegram = new Parser()
.string('timestamp', {encoding: 'hex', length: 7, formatter: time});
The Exception is:
evalmachine.:9
return moment(timestamp, 'YYMMDDHHmmssSS').format('YYYY-MM-DD HH:mm:ss.SS');
^
ReferenceError: moment is not defined
at Parser. (evalmachine.:9:2)
...
I think the Problem is that Parser don't know moment. But how can i realize that?
i have tried to import moment directly in the binary-parser module. But it doesn't working.
If i run moment outside of Parser then it is working.
Maybe anybody can help me.
The formatter function runs without the momentjs context. I am guessing because of the way it consumes the formatter property. In the code found here, the code is:
if (this.code.formatter) {
... (ctx, varName, this.options.formatter)
Because of the funny way the this keyword works, it's bound to the object (options) and because that declaration does not contain momentjs, it says that it is not defined.
You can get a better understanding of this by looking at line 735:
ctx.pushCode("{0} = ({1}).call(this, {0});", varName, formatter);
It's bound to the current object.
P.S.: I copied the code and pasted it on Node.js and it's working perfectly. ^That is a possible explanation.
Before, babel would add the line module.exports = exports["default"]. It no longer does this. What this means is before I could do:
var foo = require('./foo');
// use foo
Now I have to do this:
var foo = require('./foo').default;
// use foo
Not a huge deal (and I'm guessing this is what it should have been all along).
The issue is that I have a lot of code that depended on the way that things used to work (I can convert most of it to ES6 imports, but not all of it). Can anyone give me tips on how to make the old way work without having to go through my project and fix this (or even some instruction on how to write a codemod to do this would be pretty slick).
Thanks!
Example:
Input:
const foo = {}
export default foo
Output with Babel 5
"use strict";
Object.defineProperty(exports, "__esModule", {
value: true
});
var foo = {};
exports["default"] = foo;
module.exports = exports["default"];
Output with Babel 6 (and es2015 plugin):
"use strict";
Object.defineProperty(exports, "__esModule", {
value: true
});
var foo = {};
exports["default"] = foo;
Notice that the only difference in the output is the module.exports = exports["default"].
Edit
You may be interested in this blogpost I wrote after solving my specific issue: Misunderstanding ES6 Modules, Upgrading Babel, Tears, and a Solution
If you want CommonJS export behavior, you'll need to use CommonJS directly (or use the plugin in the other answer). This behavior was removed because it caused confusion and lead to invalid ES6 semantics, which some people had relied on e.g.
export default {
a: 'foo'
};
and then
import {a} from './foo';
which is invalid ES6 but worked because of the CommonJS interoperability behavior you are describing. Unfortunately supporting both cases isn't possible, and allowing people to write invalid ES6 is a worse issue than making you do .default.
The other issue was that it was unexpected for users if they added a named export in the future, for example
export default 4;
then
require('./mod');
// 4
but
export default 4;
export var foo = 5;
then
require('./mod')
// {'default': 4, foo: 5}
You can also use this plugin to get the old export behavior back.
For library authors you may be able to work around this problem.
I usually have an entry point, index.js, which is the file I point to from the main field in package.json. It does nothing other than re-export the actual entry point of the lib:
export { default } from "./components/MyComponent";
To workaround the babel issue, I changed this to an import statement and then assign the default to module.exports:
import MyComponent from "./components/MyComponent";
module.exports = MyComponent;
All my other files stay as pure ES6 modules, with no workarounds. So only the entry point needs a change slightly :)
This will work for commonjs requires, and also for ES6 imports because babel doesn't seem to have dropped the reverse interop (commonjs -> es6). Babel injects the following function to patch up commonjs:
function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }
I've spent hours battling this, so I hope this saves someone else the effort!
I have had such kind of issue. And this is my solution:
//src/arithmetic.js
export var operations = {
add: function (a, b) {
return a + b;
},
subtract: function (a, b) {
return a - b;
}
};
//src/main.js
import { operations } from './arithmetic';
let result = operations.add(1, 1);
console.log(result);