Develop Reference

How to debug Rollup build output with a massive encoding log?

I recently built a library with Rollup that has a few non-usual bits. That includes for instance, loading up a wasm module, workers with importScripts and a few occurences of eval() in the global scope.
Now I used the rollup-starter-app to create a demonstrator and client app for that library. The repo is https://github.com/frantic0/sema-engine-rollup
I managed to get everything working, after hitting a few walls and adding the following rollup plugins
import { wasm } from "#rollup/plugin-wasm";
import workerLoader from "rollup-plugin-web-worker-loader";
import dynamicImportVars from "#rollup/plugin-dynamic-import-vars";
import copy from "rollup-plugin-copy";
However, in the build output, I'm getting this massive log of what seems to be some encoding...
I'm not sure where this log is coming from and it is so massive that it clears out all the information of the build in the terminal...
What is the best way to tackle this issue and how to debug it effectively?

based on the suggestion #lukastaegert on the rollup issues, one solution is to redirect stderr into a file to read the log.
To do that you can add the following to your rollup command
"rollup -cw 2>err.log 1>out.log"
this allows to further inspect the build log but doesn't solve the error
[EDIT]
After a bit of peeking around Rollup's github issues and source, I found the warning categories and how to deactivate warnings.
Basically, we need to add a function onwarn to rollup.config.js. The first code section below shows the function. The second one show where we should add it on the rollup.config.js
const onwarn = (warning) => {
// Silence warning
if (
warning.code === 'CIRCULAR_DEPENDENCY' ||
warning.code === 'EVAL'
) {
return
}
console.warn(`(!) ${warning.message}`)
}
export default {= {
inlineDynamicImports: !dynamicImports,
preserveEntrySignatures: false,
onwarn,
input: `src/main.js`,
output: {

Type error: expected parameter accessToken in react Js

Error screenshot:
While running react project by npm start, it shows error related to contentful.js. why does the package shows these types of error? I attached the screenshot with this post. How to solve this issue?
.env file
CONTENTFUL_ACCESS_TOKEN: process.env.REACT_APP_CONTENTFUL_ACCESS_TOKEN,
config file
import SETTINGS from "../env";
const contentfulClient = contentful.createClient({
space: SETTINGS.CONTENTFUL_SPACE,
accessToken: SETTINGS.CONTENTFUL_ACCESS_TOKEN
});
Do i need to enter api token anywhere?
.env
const SETTINGS = {
LANDING_BLOG_POSTS: "",
ICON_TYPE: "svg",
CONTENTFUL_SPACE: process.env.REACT_APP_CONTENTFUL_SPACE,
CONTENTFUL_ACCESS_TOKEN: process.env.REACT_APP_CONTENTFUL_ACCESS_TOKEN,
CLOUDINARY_UNSIGNED_PRESET: process.env.REACT_APP_CLOUDINARY_UNSIGNED_PRESET,
CLOUDINARY_CLOUD_NAME: process.env.REACT_APP_CLOUDINARY_CLOUD_NAME,
SERVER_7CHIP: process.env.REACT_APP_SERVER_7HIP || false,
HARD_CODED_USERNAME: process.env.REACT_APP_TOKEN_USERNAME || "**********",
HARD_CODED_PASSWORD: process.env.REACT_APP_TOKEN_PASSWORD || "************",
FACEBOOK_API_ID: process.env.REACT_APP_FACEBOOK_APP_ID,
FACEBOOK_PAGE_TOKEN: process.env.REACT_APP_FACEBOOK_PAGE_TOKEN,
FACEBOOK_PAGE_ID: process.env.REACT_APP_FACEBOOK_PAGE_ID || "**************",
FACEBOOK_SERVER_CALL: true
};
export default SETTINGS;

Since your code got as far as getting into the createClient function, that tells me your SETTINGS object is loading (otherwise you'd get a TypeError from accessToken: SETTINGS.CONTENTFUL_ACCESS_TOKEN). However the error message says that no accessToken was provided.
Therefore SETTINGS.CONTENTFUL_ACCESS_TOKEN is undefined, null or an empty string. Since that value is set to process.env.REACT_APP_CONTENTFUL_ACCESS_TOKEN this probably means that you have not set your REACT_APP_CONTENTFUL_ACCESS_TOKEN environment variable before running the program.
Try setting that environment variable to your access token value, then running the program.
If that works, you might want to reconsider the approach. You have an "env" file but is getting values from system environment variables. Usually you have an "env" file so that you can hardcode values into it, not rely on them being set externally. If they have to be set externally you might as well not use an "env" file and just use process.env.VARIABLE_NAME directly in your code.
Note that if you hardcode access tokens or other private information in an "env" file, you should add that file to .gitignore so that passwords/keys are not stored in git.

You created .env.development file same location as package.json file.
hope, this will help you.

For me, I had the variables in the .env file in the source directory and just had to source it. I ran . ./.env and that sorted out the error in my case.

In my case environment variables weren't accessible, because I created the .env file when my server was already running. I had to restart the server and everything worked like a charm.

Cypress custom command is not recognized when invoked

I've created the following custom command in my cypress/support/commands.js file.
Cypress.Commands.add("login", (username, password) => {
cy.request({
method: 'POST',
form: true,
url: '/test/login/',
body: {'username': username, 'password': password}
})
})
I had tests passing and login working before moving the login functionality to this custom command. I'm invoking it in my spec with cy.login(testuser, testpwd), but I'm getting the following error message: TypeError: cy.login is not a function. The docs say that /cypress/support/commands.js is loaded before any test files are evaluated, so I assumed that simply placing a custom command in there would make the command available. I'm running the tests through the local (GUI) test runner.

All the code and referenced modules in index.js are loaded before your test file. So you need to refer(require) commands.js in your index.js file.
You can however import commands.js module directly in your test file but then you need to include it every test file.
Recommended approach is to include it in index.js file and you are not worried about explicitly refer in your test files.

To expand on #Dinesh Kumar's excellent answer, it's also important you haven't disabled support for the default support file (I know, unfortunate naming scheme in this case) inside your cypress.json by adding the line: supportFile: false.
Delete that line from your cypress.json if it's there. You can also specify a different path if you're not happy using the default path of cypress/support/index.js.
Working index.js with commands.js file - both in the support folder:
// index.js
const customCommands = require('./commands.js')
module.exports = {
commands: customCommands
}
And double check your settings:
// cypress.json
{
"baseUrl": "http://demo.your-domain.test",
"supportFile": false, // <-- delete this line present
...
}

It may help to put a line import './commands.js' into index.js.

For me it worked when I added the type signature of the custom command in the file cypress/support/index.d.ts. For more information visit: Cypress example - Custom Commands
declare namespace Cypress {
interface Chainable {
clearLocalStorageIframe(): void
}
}
I am using 7.2.0 Cypress and command.ts and index.ts file extension I have changed it to .ts

TL;DR: Check if your IDE tried to resolve cy
I slipped into this problem, because my IDE's autocomplete feature added a dependency to resolve the undeclared cy object – that gets injected by cypress.
const { default: cy } = require('date-fns/esm/locale/cy/index.js');
This was very unfortunate, as there is an ongoing (in 2022) issue with the custom commands and you can find a tons of hints..

Removing
import { cy } from "date-fns/locale";
or similar import
from the test file, resolved this. This gets added automatically to resolve undeclared cy objects
Permanent Solution: Add the following to cypress.json
"compilerOptions": {
"types": ["cypress"]
}

I added at the top of commands.js.
/// <reference types="cypress" />
export{}
//CUSTOM COMMANDS...
This then exported and exposed the custom commands after cy. .

TypeScript "import { myVar }" syntax seems to be incorrectly compiling in a Node/CommonJS/ES5 app

In my Node application, I have a settings file that exports some settings as an object like this:
// settings.ts
export var settings = {
port: 1234
}
In another file, I import these settings and attempt to reference the port property:
// another-file.ts
import { settings } from './settings';
console.log(settings.port);
This code compiles correctly, but at runtime I get the following error:
Cannot read property 'port' of undefined
When I inspect the compiled code, I can see that this is happening because my second file above is compiling to this:
var settings_1 = require("./settings");
console.log(settings_1.settings.port);
If I walk through the compiled code with my debugger, I can see that the settings_1 variable points to the exported value from settings.ts. In other words, my port property lives at settings_1.port, not at settings_1.settings.port. It seems the TypeScript compiler should instead generated this JavaScript code:
var settings = require("./settings");
console.log(settings.port);
Am I doing something wrong? Or is the TypeScript compiler incorrectly compiling my import?
I know that the TypeScript compiler is correctly type-checking my import; if I do something like this:
import { settings } from './settings';
console.log(settings.propertyThatDoesNotExist);
I get compiler errors that propertyThatDoesNotExist doesn't exist.
I'm using TypeScript 2.3.2, targeting "es5" and outputting "commonjs" modules, running on Node 6.9.2.

Figured it out. It was a silly mistake on my part (isn't it always?). I was working on converting an application from JavaScript to TypeScript, and I copied and renamed settings.js to settings.ts... but I didn't delete settings.js. As a result, I was actually importing my old settings.js file which had its exports set up differently.
Once I deleted settings.js, my application started correctly using the .ts file instead, and my imports worked as expected.

eslint /* exported functionName */ not working in browser env

I have a few functions that are defined in one js file and used in others. They each have /* exported functionName */ comments and I have my eslint env set to browser/jquery. Based on my reading of the documentation that's all I should need, but it doesn't seem to be working.
What am I doing wrong here?
Here's the .eslintrc (it extends this one, although I get the same behavior without the extends):
{
"extends": "../../.eslintrc",
"env": {
"browser": true,
"jquery": true
}
}
And, here's one of the functions (here's the second and third):
/**
* Returns the next hour as Date
* #return {Date} the next hour
*/
/* exported nextHour */
function nextHour() {
var oneHour = new Date();
oneHour.setHours(oneHour.getHours() + 1);
return oneHour;
}
Finally, this is the output I get from eslint:
/Users/nfriedly/visual-recognition-nodejs/public/js/demo.js
24:10 error 'nextHour' is defined but never used no-unused-vars
37:10 error 'resize' is defined but never used no-unused-vars
/Users/nfriedly/visual-recognition-nodejs/public/js/use.js
26:10 error 'setupUse' is defined but never used no-unused-vars
It works if I replace the /* exported... comment with an // eslint-disable-next-line no-unused-vars but I know that's not the correct solution.
You can check out the complete project from https://github.com/watson-developer-cloud/visual-recognition-nodejs/tree/eslint-exported and then just run npm install; npm test if you want to see it for yourself.

Apparently the Babel-ESLint parser that the airbnb config specifies can override the parsing of config files to break the documented cascading behavior. Setting "parser": null resolves this.

Your config states that you are working in Node environment. Node has an extra scope around every module, so global variables are not really possible in Node (at least not in the same way as in browser). As such, when no-unused-vars rule sees any environment with globalReturn flag on (Node, CommonJS, shared-node-browser) or modules on, it ignores /* exported */ comments. You need to remove Node environment and enable browser environment if you want to use global variables and exported comments.