I just start to write some codes in react in VScode but after creating a default project by "create-react-project" based on the Mosh tutorial. I have some warning by VS code when I open APP.JS as shown below.
would you mind tell me why I am receiving these warning? I am confused about what is right and what is wrong in my code.
[standard] Unexpected usage of doublequote. (jsx-quotes)
...is an ESLint rule, details of which, can be found here - You've got a few choices:
Disable ESLint (probably via some VS Code extension) or a setting thereof
Use inline disabling for specific rules (generally frowned upon)
Continue to use ESLint for coding standards and use only single quotes.
Related
I've just updated some depencencies in a React project using npm install and the updated project works nicely on all browser except Safari.
On Safari it shows a blanks screen and an error in the console:
SyntaxError: Invalid regular expression: invalid group specifier name
file: 2.f80ba52b.chunk.js
I can exclude breaking changes from updated dependencies, otherwise it would have broken on other browsers too. Despite that, I cannot figure out what is causing it.
Even if similar questions exist, and the root cause has been already recognized as the missing Safari support for lookbehind regex, I would like to provide a general way to handle those situations where, as described in the main question, you can not just fix a line of code - for example when the issue is caused by an external library.
How to handle broken external depencencies
In my case, the bug had been introduced with draft-js-utils 1.4.1, so I solved it downgrading to the first know working version (1.4.0). In order to achieve this, I edited the package.json file changing the dependency line from
"draft-js-utils": "^1.4.0"
to
"draft-js-utils": "1.4.0"
TIP: Avoiding the caret range, you can stick it to a specific version.
How to find broken external depencencies
The only way to find out what dependencies have been affected by this bug is to look for the error message in Github/Gitlab search - currently almost 300 public repositories have a related issue opened.
The hardest thing about this bug is that it could be hidden inside transitive dependencies.
You might not even know you are using that package.
If you are not lucky enough to spot it using a Github/Gitlab search, you could try with a local search using your IDE or grep. You need to look for the lookbehind symbols ?<!:
grep -r "?<\!" node_modules
Being a last resort, this approach could be either very slow or produce a huge-and-hard-to-read output.
A sad note
It looks like Webkit developers are not going to add lookbehind regex support soon - the issue has been created in July 2017 without receiving attention from them. Moreover, even if the Safari's issue has been recognized and tracked, no polyfill exists to fix it at the build level (e.g. using Babel).
I just want to add that I spent a week downgrading Babel and other packages to pre-2018 packages, only to realise that my problem was in a helper function within my own code that was to filter for malicious html code.
#lifeisfoo mentions to grep for the string '?<!' above in node_modules, but i recommend also grepping the entire project.
fyi, my regex that was breaking Safari was '?<=!'. Which is also an unsupported lookbehind
I tested my regex: (?<=![)(.*?)(?=]) in Safaris regex tester https://www.regextester.com/ and the output says 'Lookbehind is not supported in Javascript'
To end, I found Safaris console error message worthless and spread around the 10,000s of lines of the bundle.js, giving the impression that the issue was within the packages/dependancies, which it clearly was not.
I spent ages downgrading the packages only to find the same error message appear on a different line of the bundle.js code.
I've recently started using TypeScript with Expo. I've done all the linter/formatter integrations like typescript-eslint so I can catch most of the errors during coding. To check if the code compiles, I run npx tsc every once in a while and fix accordingly.
One thing that I haven't fully grasped yet is why my app builds successfully even when there are numerous compile errors. I expect (and prefer) to see a red screen error for every compile error rather than the app build successfully and me find it out later. For example,
function square<T>(x: T): T {
console.log(x.length); // error TS2339: Property 'length' does not exist on type 'T'.
return x * x;
}
is a typical TypeScript error that (I believe?) can be easily checked at compile time. I want it to result in a big red screen error and the build to fail.
I'm quite new to TypeScript so it's possible that I'm missing something very important. What exactly is causing this leniency and is there a way to enforce stricter checks?
The first thing to understand is that Typescript is a superset of Javascript, and in this case it doesn't actually get type checked during compilation.
Essentially what happens is Babel just strips out the Typescript and converts it to Javascript, which then gets compiled into the js bundles.
You can take a look at the first line of the following Babel docs as well as the caveats:
https://babeljs.io/docs/en/next/babel-plugin-transform-typescript
Since Babel does not type-check, code which is syntactically correct, but would fail the TypeScript type-checking may successfully get transformed, and often in unexpected or invalid ways.
What I would suggest is extending your build command to first include tsc or rather Typescript compilation, with noEmit set to true in your tsconfig.
Update: I found another instance where this applies recently when adding jest and typescript to a project. At the bottom of the Jest docs they actually state the same thing:
https://jestjs.io/docs/en/getting-started#using-typescript
However, there are some caveats to using TypeScript with Babel. Because TypeScript support in Babel is transpilation, Jest will not type-check your tests as they are run. If you want that, you can use ts-jest.
The straight answer to this question is: Babel, strips out all typescript marks before compiling. Therefore you won't see it erroring out in the cli.
Recently I was facing an issue coding React app on Visual Studio code. Because of this issue, whenever I wrote JSX inside the render function of the React Component and saved it, it would go messed up (I mean indentation would get messy). See the pic:
This error was also showing error like:
1. Unclosed regular expression
How to solve this?
If you are using jshint plugin, remove it and install ESLint plugin.
It is a good replacement for jshint in reactJS work.
I tried several options like creating a .eslintrc file or .jshintrc file.
But it turned out that in my Visual Studio Code IDE, there was third party extensions(eslint/jslint/tslint/beautify/jsformatter etc) that were causing a big mess in my JSX code.
I had to go to the extensions and disable all the extension which could hinder in the natural process of linting and code cleaning of React framework.
(These extensions are really great. But disabling them helped me in solving this issue of mine, no offense to anyone.)
If you are facing the same issue and the issue persists event after adding a .jshintrc with content:
{
"esversion": 6
}
then consider disabling the third party extensions.
Hope my answer helped.
the extension that did it for me was...
jshint
dbaeumer.jshint
Dirk Baeumer
as #abhay-shiro says, disabling a few extensions will usually resolve the issue.
I had the same problem, but it was "beautify" extension which was causing the error, I uninstalled it and installed prettier. It fixed the problem.
I solved this issue by disabling show syntax errors checkbox in visual studio 2015.
Tools -> options - > text editor -> javascript -> intelliSense -> general -> show syntax errors(disable)
I would like to get a more helpful exception that this one:
Uncaught Error: Minified exception occurred; use the non-minified dev environment for the full error message and additional helpful warnings.
I am trying to build a Reagent app without the usual minified React JavaScript library. This is where I have got so far with the project.clj file:
(defproject cljsbin "0.1.0-SNAPSHOT"
:dependencies [
[org.clojure/clojure "1.7.0"]
[compojure "1.1.8"]
[hiccup "1.0.5"]
[ring "1.3.0"]
[ring/ring-json "0.3.1"]
[org.clojure/clojurescript "1.7.48"]
[me.raynes/fs "1.4.6"]
[reagent "0.5.1-rc3"]
;[re-com "0.6.1"]
]
:cljsbuild { :builds [ :optimizations :none]}
:main ^:skip-aot core)
So far I have put the important (is it?) :optimizations :none in a few places in the lein project file, but always the minified React library is included.
Later...
Well I'm now quite sure I should be looking at the artifacts. What :optimizations means is covered here: https://github.com/clojure/clojurescript/wiki/Quick-Start: having optmizations gets rid of the 'goog' is undefined error messages.
So I am now using this:
;[reagent "0.5.1-rc3"]
[reagent "0.5.1-rc3" :exclusions [cljsjs/react]]
[cljsjs/react-with-addons "0.13.3-0"]
, which is important because it shows (definitively) that the reagent library includes the react library, and that this react library can be modified. Now just to find out how to get the non-minified version and I'll be able to answer my own question...
Are you sure that once you use the add-ons version, your not already getting the mimified version? I ask as the docs on the cljs/package site say
The externs file includes definitions for TestUtils but to use those with :advanced optimizations you'll need to override :file-min to use non-minified version:
which would indicate that perhaps this uses the non-mimified version unless you use :advanced compilation flag? Perhaps check the externs file and see what it has?
The other solution might be to adopt the approach on the reagent page for using your own build of reagent. To do this, I'm assuming you have to provide a bare bones cljs/react file and add the react js directly into your page?
I started using Typescript with Webstorm today and I am getting real crazy understanding what's going on. Imagine a project using tsd loading definition types on typings/. For background, angular defines an angular module aliased to ng and then there is other d.ts files appending more modules into angular (and technically ng).
When I require for example the router I get:
In fact, if you go to angular-route.d.ts (from DefinitelyTyped) you can see the same:
The d.ts files are technically correct because tsc compiles them giving it those definition files.
On the other hand, Webstorm allows you to load libraries (typescript stubs from DefinitelyTyped). If I go there and I download the angular ones (which are 100% the same as the one I have on typings/) I get:
Same error but at least I don't get the red wiggle in the solution explorer. Still, it doesn't give me any intellisense when writing ng.route.<ctrl+space>, it just turn blue when I finish writing it (in fact, I can cmd+click and go to the definition).
Who's failing here? The typescript plugin? It is weird that it fails using typings/ and somehow work with Webstorm's libraries menu (using the same file).
Who's failing here? The typescript plugin?
Yes. You need to use the Webstorm beta channel to get support for TypeScript 1.4 union Types at the moment.