Vue.js stuck on serving at 40% how to recover? - node.js

I decided to delete the node modules folder, do a npm install then do a npm run serve it always gets stuck around 40% and stays there forever. When done from the UI it also gets stuck on a similar amount:
$ vue-cli-service serve --open --mode development --https --dashboard
INFO Starting development server...
40% building 118/134 modules 16 active
...tApp\node_modules\axios\lib\defaults.js
another time:
40% building 134/147 modules 13 active
...\node_modules\axios\lib\adapters\xhr.js
I notice Node.js process is constantly going at around 15%, but nothing happens if I wait and wait and wait.
Package.json
{
"name": "myapp",
"version": "0.1.0",
"private": true,
"scripts": {
"serve": "vue-cli-service serve",
"build": "vue-cli-service build",
"lint": "vue-cli-service lint",
"test:e2e": "vue-cli-service test:e2e",
"test:unit": "vue-cli-service test:unit"
},
"dependencies": {
"#aspnet/signalr": "^1.1.4",
"axios": "^0.18.0",
"vue": "^2.6.10",
"vue-axios": "^2.1.4",
"vue-router": "^3.0.6",
"vuex": "^3.1.1"
},
"devDependencies": {
"#vue/cli-plugin-babel": "^3.7.0",
"#vue/cli-plugin-e2e-cypress": "^3.7.0",
"#vue/cli-plugin-eslint": "^3.7.0",
"#vue/cli-plugin-unit-jest": "^3.7.0",
"#vue/cli-service": "^3.7.0",
"#vue/eslint-config-standard": "^4.0.0",
"#vue/test-utils": "^1.0.0-beta.20",
"babel-core": "7.0.0-bridge.0",
"babel-eslint": "^10.0.1",
"babel-jest": "^23.6.0",
"eslint": "^5.16.0",
"eslint-plugin-vue": "^5.2.2",
"node-sass": "^4.12.0",
"sass-loader": "^7.1.0",
"vue-template-compiler": "^2.6.10"
},
"eslintConfig": {
"root": true,
"env": {
"node": true
},
"extends": [
"plugin:vue/essential",
"#vue/standard"
],
"rules": {
"space-before-function-paren": [
"error",
{
"anonymous": "always",
"named": "always",
"asyncArrow": "always"
}
],
"keyword-spacing": [
"error",
{
"after": true
}
],
"semi": [
"error",
"always"
],
"indent": "off",
"vue/script-indent": [
"warn",
2,
{
"baseIndent": 1
}
]
},
"parserOptions": {
"parser": "babel-eslint"
}
},
"postcss": {
"plugins": {
"autoprefixer": {}
}
},
"browserslist": [
"> 1%",
"last 2 versions",
"not ie <= 8"
],
"jest": {
"moduleFileExtensions": [
"js",
"jsx",
"json",
"vue"
],
"transform": {
"^.+\\.vue$": "vue-jest",
".+\\.(css|styl|less|sass|scss|svg|png|jpg|ttf|woff|woff2)$": "jest-transform-stub",
"^.+\\.jsx?$": "babel-jest"
},
"moduleNameMapper": {
"^#/(.*)$": "<rootDir>/src/$1"
},
"snapshotSerializers": [
"jest-serializer-vue"
],
"testMatch": [
"**/tests/unit/**/*.spec.(js|jsx|ts|tsx)|**/__tests__/*.(js|jsx|ts|tsx)"
],
"testURL": "http://localhost/"
}
}
$ node --version v10.15.3
How do I recover from this?
Update:
There is something magic about the number 40, I removed all mentions of Axios and now I still get stuck at 40% but with a different thing:
40% building 133/146 modules 13 active
...abel\runtime-corejs2\core-js\promise.js

In my case:
It was an error into the template.
Make sure there is a container tag just after
<template><container_tag> ... your code ...</container_tag></template> it could be as simple as a <div>

Try running npm run lint and see if you've got some errors in your code.
I had accidentally left an v-bind:attribute empty, e.g. <el :items=""></el>. Once resolved, I was able to build/serve.

// vue.config.js
module.exports = {
chainWebpack: (config) => {
config.resolve.symlinks(false)
}
}
Link: https://cli.vuejs.org/guide/troubleshooting.html#running-installation-enter code herewith-sudo-or-as-root

In my case:
git conflicts left >>>>>> master in the component, which stopped it from compiling

I my case there was:
git conflict
a tag was not completely closed it was like <div> ..... </div but vs code was not showing this error. when I opened every component, it highlighted the error

Check all your components for merge conflicts.
If you're using vscode, try to search for the string >>>>> on your project folder.

This seems to be caused by an error in one of your project files which prevents compilation and also compresses any error message.
I was personally bothered by this today, and spent a lot of time unnecessarily debugging WSL before finding the error in one of my components.
Try to comment out or remove any components, in templates, component registrations and imports, until it starts loading again.

I ran a linter as a step before serve and noticed that it corrected one of the files. It still didn't run. But I decided to go through the file and noticed that there was one closing tag missing.
It will be tedious, but look through your components to see whether you have a missing closing tag.
I also found that checking the first place the numbers pause and using that as a way to narrow down the file with a problem helped me sort it out faster.
40% building 223/268 modules 45 active ...rders\List.vue?

In my case, one of the environment variables wasn't defined. After I defined it using Webpack DefinePlugin, it all started working again. It would be great to see an actual error in such a case instead of the build process hanging.

I solve this problem by add .eslintignore file. Because I use a big packed third-party module directly in project.

It is most likely due to an error in your source files. In my case I started by removing an import of a deleted component in the main.js, then I removed a few <style> tags from two components (vue prohibits tags that have side effects in template). It may also help to monitor the last files being processed to get a clue about where to look at.

I wasn't missing any tags, but I had copied from my data section in the script to a v-if tag (to ensure I spelled the data variable properly) and I accidentally left the : instead of changing it to an =.
If you are having this problem, it might be something else to check for. It was pretty hard to see! But by removing sections of the code a piece a a time I zeroed in on it.

Related

How to import d3.js in a node and typescript project? [ERR_REQUIRE_ESM]

I'm working on a node project using typescript, oclif and d3.js, among other things. Typescript was configured by npx when creating the project with oclif so I didn't control all aspects of it (especially regarding TS, and I'm not an expert. TS is great, but configuration wise, meh).
Anyway, everything was working fine, but I recently added d3 as a dependency and tried to build a document, and I get this error when running it:
(node:22554) [ERR_REQUIRE_ESM] Error Plugin: dbacl [ERR_REQUIRE_ESM]: require() of ES Module /dbacl/node_modules/d3/src/index.js from /dbacl/src/tree/graph-tree.ts not supported.
Instead change the require of index.js in /Users/nico/Furo/Dev/dbacl/src/tree/graph-tree.ts to a dynamic import() which is available in all CommonJS modules.
In the file where I'm using d3 I import it as per documentation:
import * as d3 from 'd3'
I suspect it might be a problem after compiling, so here is tsconfig.json. I didn't change anything since generation by npx.
{
"compilerOptions": {
"declaration": true,
"importHelpers": true,
"module": "commonjs",
"outDir": "dist",
"rootDir": "src",
"strict": true,
"target": "es2019",
},
"include": [
"src/**/*"
]
}
And in case it's more relevant, here is my package.json file as well (didn't change anything either):
{
"name": "dbacl",
"version": "0.0.0",
"description": "",
"author": "",
"bin": {
"dbacl": "./bin/run"
},
"license": "MIT",
"main": "dist/index.js",
"repository": "*****/dbacl",
"files": [
"/bin",
"/dist",
"/npm-shrinkwrap.json",
"/oclif.manifest.json"
],
"dependencies": {
"#oclif/core": "^1",
"#oclif/plugin-help": "^5",
"#oclif/plugin-plugins": "^2.0.1",
"#types/d3": "^7.4.0",
"#types/jsdom": "^16.2.14",
"d3": "^7.6.1",
"directory-tree": "^3.3.0",
"jsdom": "^20.0.0",
"lodash": "^4.17.21"
},
"devDependencies": {
"#oclif/test": "^2",
"#types/chai": "^4",
"#types/mocha": "^9.0.0",
"#types/node": "^16.9.4",
"chai": "^4",
"eslint": "^7.32.0",
"eslint-config-oclif": "^4",
"eslint-config-oclif-typescript": "^1.0.2",
"globby": "^11",
"mocha": "^9",
"oclif": "^3",
"shx": "^0.3.3",
"ts-node": "^10.2.1",
"tslib": "^2.3.1",
"typescript": "^4.4.3"
},
"oclif": {
"bin": "dbacl",
"dirname": "dbacl",
"commands": "./dist/commands",
"plugins": [
"#oclif/plugin-help",
"#oclif/plugin-plugins"
],
"topicSeparator": " ",
"topics": {
"hello": {
"description": "Say hello to the world and others"
}
}
},
"scripts": {
"build": "shx rm -rf dist && tsc -b",
"lint": "eslint . --ext .ts --config .eslintrc",
"postpack": "shx rm -f oclif.manifest.json",
"posttest": "yarn lint",
"prepack": "yarn build && oclif manifest && oclif readme",
"test": "mocha --forbid-only \"test/**/*.test.ts\"",
"version": "oclif readme && git add README.md"
},
"engines": {
"node": ">=12.0.0"
},
"keywords": [
"oclif"
],
"types": "dist/index.d.ts"
}
I find this problem quite confusing because everywhere I've been searching about this problem, it seems I'm doing the right thing. I assume the problem might be between my screen and my chair, but really I don't get it. Also, should I use the dynamic import like this?
const d3 = await import('d3')
I tried, it didn't work. I made the function that generates the document async and added that line at the start but nope. Anyway, if I believe the error, that would be the way to go but I didn't see this solution anywhere when looking for a solution to my problem. What do you guys think?
Thanks
So thanks to the input from a colleague and this article, the problem is that d3 now supports ESM only. So when the compiler turns the import into
// index.ts
import * as d3 from 'd3'
// compiled index.js
const d3 = require('d3')
it just doesn't work. I was using d3 version 7, and a quick fix to it was to downgrade to version 6.7.0, when it did support commonJS.
Now, I have to move on with this project, but I'll keep looking into it and into how I can use a recent version of d3 in my project. If I do, I'll edit that answer!
Cheers

How to get babelify 10 to target a browser

What I want is
To be using the latest versions of the libraries.
For it to run in IE 11.
I'm building a react app and in order to run the tests I need #testing-library/react. In order to run the tests in a browser I need browserify. In order to run the tests in every browser I support I need babelify. However no matter what I try the babelify does nothing (and IE 11 doesn't support ... or => syntax it generates).
Here's the relevant part of package.json (some dependencies are likely not needed):
"dependencies": {
"#babel/cli": "^7.8.4",
"#babel/core": "^7.9.6",
"#babel/plugin-proposal-class-properties": "^7.8.3",
"#babel/plugin-transform-arrow-functions": "^7.8.3",
"#babel/polyfill": "^7.8.7",
"#babel/preset-env": "^7.9.6",
"#babel/preset-react": "^7.9.4",
"#testing-library/react": "^10.0.4",
"babelify": "^10.0.0",
"browserify": "^16.5.1",
"react": "^16.13.1",
"react-dom": "^16.13.1"
},
"browserslist": [
"IE 11"
]
The code that looks like it should work:
require('browserify')({
entries: ['./node/ReactUtil.js']
})
.transform("babelify", {
presets: [['#babel/preset-env', {"targets": {
"browsers": ["ie < 8"]
}}]]
})
.bundle()
.pipe(fs.createWriteStream("javascript/generated/ReactUtil.js"));
I've tried the string babelify and require("babelify"). I've tried require("babelify").configure. I've tried having a file named babel.config.json, .babelrc, and .babelrc.json in the working directory. I've tried babel.config.js in the working directory (which has a different format). (The contents of these files have been excluded to prevent tl;dr).
The generated file isn't different (or is empty) and there's no error. The only thing that gave me an error was:
.transform('babelify', {
"presets": [
[
"env", //Error: Cannot find module 'babel-preset-env'. Did you mean "#babel/env"?
{
"targets": {
"browsers": [
"ie < 8"
]
}
}
]
]
})
So I changed the "env" to "#babel/env" and babelify did nothing... The transform can't come after bundle or pipe and if I try running #babel/core after this (output a different file name) there's a race condition because browserify hasn't finished writing the file yet.
I wouldn't be totally opposed to switching tools but I figured that babelify should be able to work as expected. Maybe babelify doesn't support the newer versions I'm on? I couldn't find documentation for babelify targeting a browser and examples/other stack overflow are old or didn't work. There's too many possible combinations to try. Note that this works fine in Chrome so the browserify part is working fine.

"Windows cannot access the specified..." .Exe's made by electron-packager nor electron-forge

I'm on a Win 8.1 x64 machine. When I try to run the generated Windows binaries, I get a Windows error message.
Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.
What I've tried:
I've checked permissions, my UAC account already had full control.
I switched from using electron-forge make to electron-packager [folder] [projectTitle] --platform=win32 --arch=x64 (same error)
I updated npm, electron, electron-packager, electron-forge, and at one point had to install locally a series of packages and juggle some things from dep to devdep
In particular, I had to move electron dependency to the devdeps section in order to satisfy electron-forge
Copied the .exe to a different folder e.g. e:\ and tried running it from there (same error)
Running as Administrator (same error)
Changed electronPackagerConfig.packageManager to false per the recommended workaround for this recent known issue about pruning failing (not related to this problem, but it's a factor in play)
Opened both .exe's in 7zip and noticed that the one generated by electron-forge didn't have much in it. This may be nothing or it may correlate with the console output for that command, below.
My Goal:
This is my first electron app (I come from a web background). I'm doing this build as a sanity check before I start significantly integrating my app with electron's API.
Output of commands
electron-forge make
$ electron-forge make
We need to package your application before we can make it
[BABEL] Note: The code generator has deoptimised the styling of "E:/cygwin64/tmp/electron-packager/win32-x64/fictionDB-win32-x64/resources/app/.tmp/public/js/ckeditor/ckeditor.js" as it exceeds the max of "500KB".
[BABEL] Note: The code generator has deoptimised the styling of "E:/cygwin64/tmp/electron-packager/win32-x64/fictionDB-win32-x64/resources/app/.tmp/public/js/jquery-ui/jquery-ui.js" as it exceeds the max of "500KB".
Making for the following targets:
$
Notice how it seems to just cut off there? I wouldn't know but I'm guessing that's odd.
electron-packager . fictionDB --platform=win32 --arch=x64
$ electron-packager . fictionDB --platform=win32 --arch=x64
Downloading tmp-50796-1-SHASUMS256.txt-7.1.7
[============================================>] 100.0% of 5.56 kB (5.56 kB/s)
Packaging app for platform win32 x64 using electron v7.1.7
Wrote new app to E:\xxx\Documents\src\js_src\Projects\testbed6\fictionDB-win32-x64
$
package.json
{
"name": "fictionDB",
"private": false,
"version": "0.0.0",
"description": "A way for fiction writers to plan & organize",
"keywords": [
"organize",
"database",
"fiction",
"novel",
"stories",
"characters",
"events",
"locations",
"settings"
],
"dependencies": {
"#sailshq/connect-redis": "^3.2.1",
"#sailshq/lodash": "^3.10.3",
"#sailshq/socket.io-redis": "^5.2.0",
"acorn": "^7.1.0",
"ckeditor": "^4.12.1",
"connect-redis": "^4.0.3",
"electron-compile": "^6.4.4",
"electron-squirrel-startup": "^1.0.0",
"grunt": "^1.0.4",
"jquery": "^3.4.1",
"jquery-ui-dist": "^1.12.1",
"lodash": "^4.17.15",
"request": "^2.88.0",
"sails": "^1.2.3",
"sails-hook-grunt": "^4.0.1",
"sails-hook-orm": "^2.1.1",
"sails-hook-sockets": "^2.0.0",
"socket.io-redis": "^5.2.0"
},
"devDependencies": {
"babel-plugin-transform-async-to-generator": "^6.24.1",
"babel-preset-env": "^1.7.0",
"babel-preset-react": "^6.24.1",
"electron": "^7.1.7",
"electron-forge": "^5.2.4",
"electron-prebuilt-compile": "4.0.0",
"eslint": "5.16.0"
},
"scripts": {
"start": "electron-forge start",
"test": "npm run lint && npm run custom-tests && echo 'Done.'",
"lint": "./node_modules/eslint/bin/eslint.js . --max-warnings=0 --report-unused-disable-directives && echo '✔ Your .js files look good.'",
"custom-tests": "echo \"(No other custom tests yet.)\" && echo",
"package": "electron-forge package",
"make": "electron-forge make"
},
"main": "app/launch.js",
"repository": {
"type": "git",
"url": "git://github.com/NathanHawks/FictionDB.git"
},
"author": "Nathan Hawks",
"license": "MIT",
"engines": {
"node": "^8.9"
},
"config": {
"forge": {
"make_targets": {
"win32": [
"squirrel"
],
"darwin": [
"zip"
],
"linux": [
"deb",
"rpm"
]
},
"electronPackagerConfig": {
"packageManager": false
},
"electronWinstallerConfig": {
"name": "fictionDB"
},
"electronInstallerDebian": {},
"electronInstallerRedhat": {},
"github_repository": {
"owner": "",
"name": ""
},
"windowsStoreConfig": {
"packageName": "",
"name": "fictionDB"
}
}
}
}
I forgot to turn off antivirus shields. That fixed it. (For the permanent solution, I then added a security exception in my antivirus app's settings.)
As a note of interest, the version made by electron-forge didn't work:
However, the one made by electron-packager alone, worked fine.

Change in file does not trigger reload of Node server

Windows 10, VS Code, Node 10.16.2.
I have a small project that only contains a few files - index.js and a css file mainly.
npm start starts the project and a message says Server will reload automatically if you modify any file!
This works if I modify the css file for example. But if I modify the index.js file nothing happens.
My Node setup is default. I have not manually installed any modules to watch for file changes and I don't want to. Just trying to figure out why this doesn't work for the js file.
EDIT
Below is the contents of package.json. Something else interesting is that if I allow index.js to be linted I get a weird error about the equals sign after propTypes. Someone suggested might be an issue with webpack, which I know nothing about. But they said if the file won't build because of an error then a change in the file might not be detected. Note, though, that the project runs fine.
static propTypes = {
width: PropTypes.number,
height: PropTypes.number
};
Here is package.json:
{
"private": true,
"name": "some name",
"description": "some description",
"version": "0.1.0",
"scripts": {
"start": "nr1 package:serve",
"test": "exit 0"
},
"nr1": {
"uuid": "e13bf28f-8989-4a3a-832c-7c3f0eec6c3e",
"sdkVersion": 2
},
"dependencies": {
"prop-types": "^15.6.2",
"react": "^16.6.3",
"react-dom": "^16.6.3"
},
"browserslist": [
"last 2 versions",
"not ie < 11",
"not dead"
],
"devDependencies": {
"eslint": "^6.1.0",
"eslint-plugin-react": "^7.14.3"
}
}

gulp-merge fails to output gulp-main-bower-files after .pipe

I have a css build task that merges resources from bower dependencies and my own css.
The build task is part of project that uses git source control. The project has been running correctly for well over a year.
Up until yesterday, everything was working correctly on my windows laptop, when I reinstalled my npm dependencies that run the build task.
Below is a simplified example
gulpfile.js
var gulp = require('gulp'),
$ = require('gulp-load-plugins')();
gulp.task('default', function () {
return $.merge (
gulp.src('./bower.json')
.pipe($.mainBowerFiles('**/*.css', {
includeDev: 'exclusive',
group: 'css'
})
),
gulp.src(['./source/css/styles.css'])
)
.pipe($.plumber())
.pipe($.concat('stylesheet.css'))
.pipe(gulp.dest('./build/css'))
});
package.json
{
"name": "merge",
"version": "1.0.0",
"description": "",
"main": "gulpfile.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"license": "ISC",
"devDependencies": {
"gulp": "^3.9.1",
"gulp-concat": "^2.6.1",
"gulp-load-plugins": "^1.5.0",
"gulp-main-bower-files": "^1.6.2",
"gulp-merge": "^0.1.1",
"gulp-plumber": "^1.1.0",
}
}
And bower.json
{
"name": "merge",
"description": "",
"main": "gulpfile.js",
"authors": [
""
],
"license": "ISC",
"homepage": "",
"private": true,
"ignore": [
"**/.*",
"node_modules",
"bower_components",
"test",
"tests"
],
"devDependencies": {
"normalize-css": "^7.0.0",
"reset-css": "^2.2.1"
},
"group": {
"css": [
"reset-css",
"normalize-css"
]
}
}
Prior to yesterday the task would merge both sources declared in $.merge(...). Since yesterdays' npm install I am finding that the merge will only output the result for the first declared source.
After some testing I have found that if I reverse the order of the merge sources than both sources are merged to the set output destination.
var gulp = require('gulp'),
$ = require('gulp-load-plugins')();
// the order of the sources has been reversed
gulp.task('default', function () {
return $.merge (
gulp.src(['./source/css/styles.css']),
gulp.src('./bower.json')
.pipe($.mainBowerFiles('**/*.css', {
includeDev: 'exclusive',
group: 'css'
})
)
)
.pipe($.plumber())
.pipe($.concat('stylesheet.css'))
.pipe(gulp.dest('./build/css'))
});
The problem with this solution is that that output content reversed, which may cause issues with style inheritance etc. This change to a successful output makes me think there may be an issue with how and where .pipe($.mainBowerFiles(...) is declared.
I've also tried replacing installed modules for gulp-merge and gulp-main-bower-files respectively with merge2 and main-bower-files.
Using either one or both solved the problem, however this isn't an ideal workaround as it means an update to the gulp task and installed modules.
This sudden failure to output tasks merge css ( or js ) in my project has real issues for any historic commit or branch in the project.
Is there away I can diagnose the failure of the original $.merge(...), or a way that I can retroactively replace gulp-merge with merge2 across all commits my git project and any branches?

Resources