I have husky and lint-staged set up in my package.json file and it runs, but on all files, whereas I would expect it to run on only staged files.
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"./**/*.js": [
"eslint . --fix --quiet"
]
},
Removing the "." in your eslint command should fix this.
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"./**/*.js": [
"eslint --fix --quiet"
]
},
The command eslint . --fix --quiet runs eslint on all files in the current directory.
So, when the pre-commit hook is triggered for a staged file, since your eslint command is running on all files in your current directory, it affects your unstaged files too.
Whenever lint-staged runs on a file, it automatically passes the file's name to all the specified commands.
For example, if the staged index.js file is being processed,
eslint --fix --quiet
is transformed into
eslint --fix --quiet index.js
Related
I want to minify/uglify a javascript file but after I run the script it never finishes executing. These are the scripts and dependencies I added to it.
"scripts": {
"minify": "uglifyjs -i src/*.js -o build/scripts.min.js",
"uglify": "npm run minify",
},
"devDependencies": {
"uglify-js": "^2.8.29"
}
This is the link to the package.json in my repo. What am I doing wrong? 🤔 Thanks
I'm creating a new Vue project via npm init vue#latest and select everything (Eslint with Prettier)
I'm using the following setup
OS: Win11
node: v17.4
npm: v8.4
I setup lint-staged via npx mrm#2 lint-staged. For testing purposes I add a new file inside the src directory
// calc.js
function
add
(numOne,
numTwo) {
return numOne +
numTwo;
}
When committing the new file the linter fixes the code style as expected. But after that I manually have to delete a generated .eslintcache file.
Older posts say I should add
*.eslintcache
to the .gitignore file. But I compared the generated .gitignore file with the generated one from the Vue CLI and both don't have this line. When using the Vue CLI the cache file doesn't appear.
So are there any other solutions or is there something I missed?
The .eslintcache file is created from ESLint's --cache flag, which is included in the default linter command of lint-staged:
// package.json
{
"lint-staged": { 👇
"*.{vue,js,jsx,cjs,mjs}": "eslint --cache --fix",
"*.{js,css,md}": "prettier --write"
}
}
You can either remove the --cache flag:
// package.json
{
"lint-staged": {
"*.{vue,js,jsx,cjs,mjs}": "eslint --fix",
"*.{js,css,md}": "prettier --write"
}
}
...or set the cache file location with the --cache-location flag (e.g., specify node_modules/.cache):
// package.json
{
"lint-staged": { 👇
"*.{vue,js,jsx,cjs,mjs}": "eslint --cache --fix --cache-location ./node_modules/.cache/.eslintcache",
"*.{js,css,md}": "prettier --write"
}
}
When run locally, it seems to work fine but crashes when its on pipeline
EDIT: After removing npx, it produces a different error:
I have followed the advice of installing the plugin:
npm install eslint-plugin-react#latest --save-dev
But seeps to repeat itself.
Here's my retracted bitbucket-pipelines.yml config:
- step:
name: CI
caches:
- node
script:
- npm install
- npm run lint
- npm run test
eqautes to package.json
"lint": "eslint --ext .js,.ts,.tsx src --ignore-pattern node_modules/",
"test": "jest --verbose --colors --coverage",
Here's my eslint config file:
{
"env": {
"browser": true,
"es6": true,
"jest": true
},
"extends": [
"eslint:recommended",
"plugin:react/recommended",
"airbnb"
],
"globals": {
"Atomics": "readonly",
"SharedArrayBuffer": "readonly"
},
"parser": "#typescript-eslint/parser",
"parserOptions": {
"ecmaFeatures": {
"jsx": true
},
"ecmaVersion": 2018,
"sourceType": "module"
},
"plugins": [
"react",
"#typescript-eslint"
],
"settings": {
"import/resolver": {
"node": {
"extensions": [".js", ".ts", ".tsx"],
"paths": ["src"]
}
}
},
"rules": {
...
}
}
}
An update to Visual Studio Code fixed this for me.
I was unwittingly on a 2 year old version.
Fixed it by removing NODE_ENV in pipelines's .env due to this:
npm install (in package directory, no arguments):
Install the dependencies in the local node_modules folder.
In global mode (ie, with -g or --global appended to the command), it
installs the current package context (ie, the current working
directory) as a global package.
By default, npm install will install all modules listed as
dependencies in package.json.
With the --production flag (or when the NODE_ENV environment variable
is set to production), npm will not install modules listed in
devDependencies.
NOTE: The --production flag has no particular meaning when adding a
dependency to a project.
it happened to to.
tried hard to find the answer.
Apparently, eslint searchs for a roots in the working directory, or something like that, to find the modules to import.
It happens that i've had two apps in my project folder, and only one had the eslintrc.josn.
I fixed to use eslint on the entire project oppening the vs settings.json and add the following:
"eslint.workingDirectories": ["./app1","./app2"...]
if u have more than one app on ur project folder, u should try it
I am using npm precommit hook, but it is not stopping a file with issues to be committed, nor am I getting the message "Pre commit checks" when I try to commit a file.
Package Json:
{
"name": "myfolder",
"version": "1.0.0",
"description": "",
"main": "",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 0",
"precommit-msg": "echo 'Pre-commit checks...' && exit 0",
"lint": "csslint global/css"
},
"author": "SR",
"license": "ISC",
"dependencies": {
"csslint": "^1.0.4",
"jshint": "^2.9.4",
"pre-commit": "^1.2.2"
},
"pre-commit": [
"precommit-msg",
"lint"
],
"devDependencies": {
"pre-commit": "^1.2.2"
}
}
Please, make sure that your 'package.json' file is in the same folder, where '.git' folder is (where git repository was initialized). When you install 'pre-commit' package, 'pre-commit' file should appear under '.git/hooks/'.
Just FYI I had this issue because the pre-commit file was missing in the hooks folder.
Running npm i pre-commit --save-dev again created the file and solved it for me.
Have't managed to implement it with few "pre-commit" NPM modules (#fastify/pre-commit, monorepo-staged-precommit) so implemented it "manually" with adding tools/pre-commit.sh file into repo with content like:
#!/bin/sh
DIR='web'
echo "Pre-commit actions (NPM tests for $DIR)..."
cd $DIR && npm run test
and updating package.json with:
"scripts": {
"test",
"install-precommit": "cp ../tools/pre-commit.sh ../.git/hooks/pre-commit"
This solution has some limitations (like instead of automatic installation need to ask somewhere in "README" about npm run install-precommit and I'm not sure how it would work on Windows especially without Git Bash) but it worked for me.
Notes:
Other pre-commit NPM packages either didn't work as well or asked for NVM and other extra tools which I don't want devs to install for such small task.
pre-commit.sh may has any name and don't be executable - "install-precommit" task and git care about.
When I change my files while webpack-dev-server is running, the bundle's files are not updated.
Here are my webpack.config.js and package.json files, as you can see from my npm script, I've solved running webpack watch and webpack-dev-server in the same command (npm run watch & webpack-dev-server --content-base ./ --port 9966):
webpack.config.js:
'use strict';
var ReactStylePlugin = require('react-style-webpack-plugin');
var ExtractTextPlugin = require('extract-text-webpack-plugin');
var webpack = require('webpack');
module.exports = {
devtool: 'sourcemap',
entry: ['./js/main.js'],
output: {
filename: 'bundle.js',
path: __dirname + '/assets',
publicPath: __dirname + '/'
},
module: {
loaders: [
{
test: /\.js$/,
loaders: [
ReactStylePlugin.loader(),
'jsx-loader?harmony'
]
},
{
test: /\.css$/,
loader: ExtractTextPlugin.extract('css-loader')
}
]
},
plugins: [
new ReactStylePlugin('bundle.css'),
new webpack.DefinePlugin({
'process.env': {
// To enable production mode:
//NODE_ENV: JSON.stringify('production')
}
})
]
}
package.json:
{
"name": "reactTest",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"watch": "webpack --watch",
"build": "webpack",
"web": "npm run watch & webpack-dev-server --content-base ./ --port 9966"
},
"author": "",
"license": "ISC",
"devDependencies": {
"css-loader": "^0.10.1",
"extract-text-webpack-plugin": "^0.3.8",
"jsx-loader": "^0.13.1",
"react-style-webpack-plugin": "^0.4.0",
"style-loader": "^0.10.2",
"url-loader": "^0.5.5",
"webpack": "^1.8.5",
"webpack-dev-server": "^1.8.0"
},
"dependencies": {
"react": "^0.13.1",
"react-style": "^0.5.3"
}
}
my directory structure is:
assets
bundle.css
bundle.css.map
bundle.js
bundle.js.map
js
AppActions.js
Profile.css.js
ProfileList.js
main.js
AppConstants.js
AppStore.js
Profile.js
ResultPage.js
package.json
index.html
node_modules
webpack.config.js
every file inside assets directory is generated by webpack
In order to get webpack to watch my file changes (Ubuntu 14.04), I had to increase the number of watchers (I had increased the number before, but it was still too low):
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Source in the official docs: https://webpack.github.io/docs/troubleshooting.html#not-enough-watchers
I first suspected the cause to be fsevents which doesn't work on Ubuntu, but this apparently wasn't the case.
Furthermore, because now the watching and re-compiling worked, but the automatic browser refresh part didn't work, I added the --inline param to the answer of #deowk which enables the "inline mode":
webpack-dev-server --content-base ./ --port 9966 --hot --inline
Quote from the official docs: "The easiest way to use Hot Module Replacement with the webpack-dev-server is to use the inline mode."
Source: https://webpack.github.io/docs/webpack-dev-server.html#hot-module-replacement
you need to run webpack-dev-server with the --hot flag:
webpack-dev-server --content-base ./ --port 9966 --hot
Then you can access the hot-loading version localhost:9966/webpack-dev-server/
You don't need to run watch as well.
update:
This entry in your webpack config must change:
entry: ['./js/main.js'], --> entry: ['webpack/hot/dev-server' , './js/main.js']
Change your publicPath entry:
publicPath: '/assets/'
#funkybunky identified the right problem but (IMHO) fixed it the wrong way. At least in my case, webpack was trying to watch every file it used, including a deep chain of thousands of files of dependencies pulled from npm. I added this to my config, per the docs:
devServer: {
watchOptions: {
ignored: /node_modules/
}
}
Of course you legitimately could have thousands of files that might need to be watched, in which case go ahead and raise the limit, but you're probably better off ignoring vendor libraries that aren't likely to change.
I'll put this here just in case it helps anyone. My problem was the same, but caused by inconsistent capitalization of directory names and webpack alias declaration.
I had a WebGL directory which i referenced in my aliases as webgl, and unfortunately this worked for the build, but didn't work for code watching.
In my case, the error was caused by an empty space in the directory name, by changing "Repository Name" by "RepositoryName", everything worked fine !
Figured I'd post my solution as well. I had the same problem getting Flutter apps to run on OS X due to my hard drive setup.
The gist is if your project folder is in a symlinked folder, detecting the file changes may not work on OS X. Previously, we were on Webpack 3.X, I believe, and live reload/refresh worked fine in the original folder. However, after upgrading to the latest Webpack (^5.75.0) and Webpack Dev Server (^4.11.1), the hot-reloading no longer worked for me.
My original project folder was:
/Users/blakemiller/h/somefolder/v2/my-widget
The "/h" there is a symlink to: /System/Volumes/Data/projects/home/web/
I'm not sure what happened when I upgraded OS X at some point, but the upgrade changed the folders in a way that I don't really understand.
Putting the folder here instead, fixed the issue for me (no symlink):
/Users/blakemiller/my-widget
I doubt this will work for many people, as my setup is probably pretty specific, but maybe it will help someone else save 5 hours down the road...