I have a package of custom rules which I want to pull in (eslint-config-common), then use an .eslintrc file to override some of them.
extends: common
rules:
no-invalid-this: 0 # override a rule in common
If I run it directly, it all works as expected:
./node_modules/.bin/eslint src/**/*.js
Though if I run it as an .sh file or through an NPM script like lint: eslint src/**/*.js, it doesn't pull in the extends rules. It only runs using the rules found directly in .eslintrc. In my case, that's really bad since my .eslintrc is generally just turning off or down rules I don't want to use.
I've run it with DEBUG:eslint:* and it finds and loads the proper extends file, it just doesn't seem to apply the rules.
I found a bug similar to this, which they seem to say is fixed: https://github.com/eslint/eslint/issues/2754
This bug seems similar, so I'm not sure if I'm doing something wrong, or if there is still a bug.
I'm using the latest version of eslint 3.17.1
It turned out I was using a glob without wrapping it in quotation marks. It seems like NPM chewed on it a bit and it seems like it only went down as deep as one directory.
Instead of this:
"script": {
"lint": "eslint path/to/code/**/*.js"
}
Use this:
"script": {
"lint": "eslint 'path/to/code/**/*.js'"
}
Related
From what I understand, eslint, or better typescript-eslint, can read tsconfig.json. This seems to work for me.
But I cannot call eslint without a positional argument specifying the files that should be linted. I cannot find any documentation on how to call eslint correctly without specifying the files again.
Specifying the files again is a maintenance nightmare. I could work around this by using jq to extract the correct field from tsconfig.json, but this seems like such a hack.
https://github.com/typescript-eslint/typescript-eslint/issues/853 suggests that the includes from tsconfig.json should be respected? But there is no sample of how eslint is called.
Edit:
To put in simple words: I would like to call npm run eslint, not npm run eslint path/to/ts/files.
Edit:
I'm using
FILES=`jq -r ".include[] |= \"${PROJECT_ROOT}/\" + . + \" \" | .include | add" "${PROJECT_ROOT}/tsconfig.json"`
and then npm run eslint $FILES as a workaround.
How does your package.json look like? You could specify your path there like this:
{
...
"scripts": {
"eslint": "eslint path/to/ts/files"
}
}
Background
I've been following more or less the official guide to setup a local dev environment with react and it seems to use create-react-app, which sets up really a lot.
Now, if I run npm run build I get a minified version of everything in the build folder.
If I, however, run npm start the version NodeJS serves does not seem to have any modifications. But I cannot see these files.
Question
So either:
Can I access the files generated by npm start somewhere? As these seem to be unmodified. (build is never modified there)
Or can I somehow run npm run build, so it does a "development" build with unminimized files?
Tries
My aim is just to get access to an unminimized version of react scripts.
As for the last question I've tried some parameters and enironmental variables as suggested in this question, but as you can see, it failed:
$ NODE_ENV=dev npm run build --dev --configuration=dev
> example-project#0.1.0 build [...]
> react-scripts build
Creating an optimized production build...
[...]
System
My package.json has the default scripts:
"scripts": {
"start": "react-scripts start",
"build": "react-scripts build",
"test": "react-scripts test",
"eject": "react-scripts eject"
},
Note: Please do not ask why I am doing it or try to convince me that it is bad. There are many reasons why I'd maybe want this, e.g. debugging or this specific use case.
To change the webpack config and build scripts you have either to eject from create-react-app (i would not recommend this step, as it breaks future compatibility) or use tools like rewire to override some settings
Take a look at this.
https://github.com/timarney/react-app-rewired
I personally used just rewire
npm i rewire --save-dev
Here is a sample config i created for one of my projects in the past and it worked pretty good!
Create build.js
Change your package.json so that it runs build.js
build.js
const rewire = require('rewire');
const defaults = rewire('react-scripts/scripts/build.js');
const config = defaults.__get__('config');
// Consolidate chunk files instead
config.optimization.splitChunks = {
cacheGroups: {
default: false,
},
};
// Move runtime into bundle instead of separate file
config.optimization.runtimeChunk = false;
// JS
config.output.filename = '[name].js';
// CSS. "5" is MiniCssPlugin
config.plugins[5].options.filename = '[name].css';
config.plugins[5].options.publicPath = '../';
Then in my package.json i changed the npm script links like this
(node build which will run the build.js script)
package.json
"scripts": {
"start": "react-scripts start",
"build": "node build && gulp",
"test": "react-scripts test",
"eject": "react-scripts eject"
},
So if you really want to eject from create-react-app, all you have to do is to run
npm run-script eject
Then you will get a new folder with all configs used by create-react-app
But as i said before, there is no reason why not to use rewire and just override the config instead of ejecting.
I wanted the unobfuscated code of a React app - mostly of curiosity, I had the source - while having the job of rewriting it in Angular (producing a far more maintainable app 5% of the size and 1% dependencies).
I've never used React but discovered by modifying the file
<base_path>/node_modules/react-scripts/config/webpack.config.prod.js
and replacing the large optimization config item, under module.exports, with the following...
module.exports = {...
optimization: {
minimize: false,
splitChunks: {
chunks: 'all',
name: true
},
runtimeChunk: true
},
npm run build built unobfuscated, readable code that ran as expected, using no other modifications. Used Gitbash only with the commands npm install, npm run build and npm start - Just thought someone may find that useful.
I don't recommend this because the code you want is still wrapped in a webpack eval mess. It's easier to pick the useful bits from the source or just rebuild the app. At best, I got to see what a cluster react and webpack is.
Why can't you see the source files? Here is what I would try:
Start your react app with npm run start
Open your browser to http://localhost:3000
Open Developer tools and inspect the created chunked bundles by the webpack-dev server. In Chrome on a mac, you can do the following: cmd+option+j will open developer tools. Then click the sources tab: within this tab you will see the bundles created by react's build configuration. Now the output of these bundles might not be pretty but it's all there.
Alternatively, all your application's build configuration settings are contained within your webpack.config.js file even when you use create-react-app. As this configuration is just encapsulated within the react-scripts node module. So maybe you could try editing this file directly, without ejecting: <base_path>/node_modules/react-scripts/config/webpack.config.js. Although you need to be careful as to not break an existing configuration setting. You probably want to mess with the source-map settings for production builds. At least this way if you ruin this file you can always just remove and reinstall react-scripts and be back to your initial configuration. This will also allow you to play around with your customizations in 'semi-safe' sandboxed environment. Remember, there is no magic that create-react-app is providing rather it's just making useful defaults for your build configuration.
Lastly, as #xzesstence pointed out you can try out the react-app-rewired module.
Hopefully that helps!
The files are kept in the server process memory and not written to disk, unless you eject the scripts (or if it is possible to use a tool like 'rewire') and modify them to write it to disk using the writeToDisk option as described in the webpack DevServer docs.
You can however get the actual file list/links by navigating to the webpack-dev-server endpoint under the server.
For instance if using the default url at localhost:3000 then use the following url to see all files on the server:
http://localhost:3000/webpack-dev-server
But what you really need is only the index.html (which is in general just a stub that loads the JS files) and the 3 following JS files which appear to be consistent on all create-react-app installments, along with their respective source map files.
main.chunk.js
bundle.js
vendors~main.chunk.js
You can just right click on the links on the page and save them, or you can navigate direct the link or get them from the Chrome Dev Tools "sources" tab.
Note that in general for code changes only the main.chunk.js file is updated, so for the average code change you might just fetch the updated main.chunk.js and main.chunk.js.map files.
I know it's way too late to answer this, but try this npm i -D cra-build-watch.
I feel this library is underrated but it just watch the changes in react app and does not re-build the whole package again and again.
Although rewiring helps in making the build by not minifying it, however, still it goes through the whole process of building again and again.
After spending a whole day on this problem, I could not find a way to get the none-minified version of the production code,
what I did was: open the dev tools on chrome, navigate to the sources tab; now find the javascript file (in create-react-app it is usually in static > js > main.js)
when the javascript file is visible, at the bottom left of the screen a pair of curly braces appear (look at the image):
screenshot of the dev tools
when you click on the curly braces, it beautifies the code, and then you can add breakpoints to the code (click on the number on the line ) and refresh the page to start the debugger, it is not convenient to deal with that code, but for now that is what worked for me.
hope it helps.
I just installed ESLint and I can successfully run it by doing this at the terminal window:
./node_modules/.bin/eslint app
Note: app is the root folder I want lint to inspect.
I then put that exact command in my package.json:
"scripts": {
"lint": "./node_modules/.bin/eslint app"
}
I expected to be able to run it in the terminal window like this:
npm run lint
Note: I know how to fix the no-undef error. My question is about the many errors lines after that.
It actually works, but it also produces a bunch of errors after showing me the correct output:
Why is that happening?
This is the default way of how the npm script runner handles script errors (i.e. non-zero exit codes). This will always happen, even if you only run a script like exit 1.
I'm not sure why this feature exists, it seems annoying and useless in most cases.
If you don't want to see this, you can add || true at the end of your script.
Example:
lint: "eslint app || true"
As you might've noticed, I've omitted the part to the eslint binary. The npm script runner already includes local binaries as part of the path when trying to run the script so there is no need to use the full path.
document is a global, so eslint thinks you are missing an import somewhere. For those cases, you can adapt your config so that the error is not reported, Something like this:
module.exports = {
"globals": {
"document": true
}
}
this should be saved as .eslintrc.js and be at the same level where your package.json is
This is really weird, I have the following scripts in my package.json:
"scripts": {
"lint": "./node_modules/tslint/bin/tslint src/js/**/*",
"lint:fix": "./node_modules/tslint/bin/tslint src/js/**/* --fix"
},
When I run npm run lint I don't get any errors and running echo $? immediately after shows 0.
However, if I run tslint src/js/**/* I do get linting errors.
How come?
There are a host of well-known issues in npm arising from the use of globbing. Many of them exclusively impact Windows, while others are "merely" shell-specific.
Try the following.
"scripts": {
"lint": "./node_modules/tslint/bin/tslint \"src/**/*.ts\"",
},
If this didn't immediately persuade you that computers have been a disaster for the human race, you can learn more about why these issues occur in the fantastic The Linux Programming Interface, which covers a surprising number non-Linux portability issues such as this one.
using npm run lint defaults to the tslint in the node_modules of your local project directory, while using tslint src/js/**/* defaults to the the one in your global, you should check if there is a version mismatch which could cause differences in rules
With npm-run-scripts you can omit the ./node_modules/.bin as npm will first look in there.
I'm attempting to build a package.json so that when running a NodeJS app on Heroku it will run the scripts.postinstall step using an environment variable. For example:
...
"scripts": {
"postinstall": "command $ENV_VAR"}
},
...
I've looked at the docs and wasn't able to find something saying I can.
Is this even possible? Is this even desirable and "I'm Doing It Wrong"™?
Ignore the nay-sayers. You can do this in a cross-platform manner using cross-var:
"scripts": {
"postinstall": "cross-var command $ENV_VAR"
}
Updated answer due to new packages having been written
You can use the cross-var package to do this in a clean way:
...
"scripts": {
...
"postinstall": "cross-var command $ENV_VAR",
...
},
"dependencies": {
...
"cross-var": "^1.1.0",
...
}
...
Original answer
To answer the last questions, because they're the most important one: yes, no, and absolutely, because you've just broken cross-platform compatibility. There is no guarantee your environment syntax works for all shells on all operating systems, so don't do this.
We have a guaranteed cross-platform technology available to us already: Node. So, create a file called something like bootstrap.js, and then make npm run node bootstrap as your postinstall script. Since the code inside bootstrap.js will run like any other node script, it'll have access to process.env in a fully cross-platform compatible way, and everyone will be happy.
And many, many, many things that use common utils have node equivalents, so you can npm install them, locally rather than globally, and then call them in an npm script. For instance mkdir -p is not cross-platform, but installing the mkdirp module is, and then an npm script like "ensuredirs": "mkdirp dist/assets" works fine everywhere when run as npm run ensuredirs
And for convenience, the most common unix utilities have their own runner package, shx, which is fully cross-platform and makes the lives of devs even easier, with the "if you're writing code" equivalent being fs-extra.