error unexpected assignment in

• View all errors
• JSLint errors
• JSHint errors
• ESLint errors
• View all options
• JSLint options
• JSHint options
• ESLint options

Unexpected assignment expression

This warning has existed in two forms across the three main linters. It was introduced in the original version of JSLint and has remained in all three tools ever since.

In JSLint, up until July 2013, the warning given was "Expected a conditional expression and instead saw an assignment"

In July 2013 the warning given by JSLint changed to "Unexpected assignment expression"

In both JSHint and ESLint the warning has always been "Expected a conditional expression and instead saw an assignment"

The situations that produce the warning have not changed despite changes to the text of the warning itself.

When do I get this error?

The "Unexpected assignment expression" error (and the alternative "Expected a conditional expression and instead saw an assignment" error) are thrown when JSLint, JSHint or ESLint encounters an assignment expression in an if , for or while statement initializer . In the following example we have an if statement with an assignment expression where you would normally expect a conditional:

Since May 2013 JSLint will also generate this warning when it encounters a return statement containing an assignment expression . If that's the case in your code you'll want to read the page concerning the " Did you mean to return a conditional instead of an assignment " error instead.

Why do I get this error?

This error is raised to highlight a possible mistake . Your code is unlikely to work as expected if you do not resolve this issue. However, the code in the example above is valid and will not cause fatal errors in any environment.

Instead of checking whether the variable x has the value 0 the example above will assign the value 0 to x . The body of the if statement will not be executed because the assignment expression results in undefined which is falsy.

In the above case it's obvious we've made a mistake and the fix is to simply ensure the use of a comparison rather than an assignment:

There are some legitimate situations that can produce this error too. Consider the following example which is a common pattern for traversing a DOM node heirarchy:

In this case you can disable the warning (if you're using JSHint or ESLint) or force the expression to become conditional, but only if you're using JSHint, ESLint or a version JSLint from before July 2013 (the message will be "Expected a conditional expression and instead saw an assignment"). If you're using a more recent version there appears to be no way to supress the "Unexpected assignment expression" warning:

In JSHint 1.0.0 and above you have the ability to ignore any warning with a special option syntax . The identifier of this warning is W084 . This means you can tell JSHint to not issue this warning with the /*jshint -W084 */ directive.

In ESLint the rule that generates this warning is named no-cond-assign . You can disable it by setting it to 0 , or enable it by setting it to 1 .

About the author

This article was written by Jonathan Klein, software engineer at Etsy, focusing on solving web performance and scalability challenges. He started and organizes the Boston Web Performance Meetup Group.

Follow me on Twitter  or  Google+

This project is supported by orangejellyfish , a London-based consultancy with a passion for JavaScript. All article content is available on GitHub under the Creative Commons Attribution-ShareAlike 3.0 Unported licence.

Have you found this site useful?

Please consider donating to help us continue writing and improving these articles.

Unexpected assignment statement in module?

Daniel Carrera

Erik Toussaint

James Van Buskirk

> integer, parameter :: p = pref > real(p) :: ck_a(6,6) = reshape( (/ & > 0.0_p , 0.0_p , 0.0_p , 0.0_p , 0.0_p , > 0.0_p , & > 1.0_p/5 , 0.0_p , 0.0_p , 0.0_p , 0.0_p , > 0.0_p , & > 3.0_p/40, 9.0_p/40 , 0.0_p , 0.0_p , 0.0_p , > 0.0_p , & > 3.0_p/10, -9.0_p/10 , 6.0_p/5 , 0.0_p , 0.0_p , > 0.0_p , & > -11.0_p/54, 5.0_p/2 , -70.0_p/27 , 35.0_p/27 , 0.0_p , > 0.0_p , & > 7.0_p/8 , 1631.0_p/55296, 175.0_p/512, 575.0_p/13824, > 44275.0_p/110592, 253.0_p/4096 & > /), (/ 6, 6 /) )

integer, parameter :: p = pref

Richard Maine

> On 04/30/2011 04:28 PM, Erik Toussaint wrote: > > It is not allowed to have executable statements by themselves in a > > module. They need to be inside a procedure, or in the main program. > > Hmm... I need some module constants that are shared by several > procedures. That's why I had those variables in the module directly.

> Hmm... It looks like I can still assign a value in the variable declaration: > > real(pref) :: foo = 3

Note that is not an assignment statement. It is an initialization. It doesn't require execution to happen. Instead, it defines the value of the variable when the program starts. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain

module ode use types implicit none real(pref) :: ck_c(6), ck_b4(6), ck_b5(6), ck_a(6,6)

contains subroutine init

ck_c = (/ 0, 1/5, 3/10, 3/5, 1, 7/8 /) ck_b5 = (/ 37/378, 0, 250/621, 125/594, 0, 512/1771 /)

Tobias Burnus

> reshape( [ real(p) :: 0, 0, 0, 1.0_p/5.0_p, 0, 0, ... ], [6,6]) > > The "real(p) :: " makes sure that the constructed array has that type; I > think it is required if elements have different types.

(I think I counted the blanks right, but no guarantee). In f90/f95, the need for careful blank counting deterred me from using character array constructors most of the time.

> The "real(p) :: " makes sure that the constructed array has that type; I > think it is required if elements have different types. You still need to > add the _p for, e.g. 1.0_p/5.0_p as you might loose digits when you use > "1.0/5.0" - or more obviously "1/5" (= 0).

Ok. Thanks.

Ron Shepard

> Well, you could write: > > reshape( [ real(p) :: 0, 0, 0, 1.0_p/5.0_p, 0, 0, ... ], [6,6]) > > The "real(p) :: " makes sure that the constructed array has that type; I > think it is required if elements have different types. You still need to > add the _p for, e.g. 1.0_p/5.0_p as you might loose digits when you use > "1.0/5.0" - or more obviously "1/5" (= 0).

real(p) :: ck_a(6,6) = reshape( (/ &

(/ 6, 6 /) )

$.02 -Ron Shepard

ck_a(6,6) = reshape( [ real(p) :: 0_p, 1.0_p, 1.5555555555_p, 1.0_p/5.0_p, ... ], [6,6])

>> add the _p for, e.g. 1.0_p/5.0_p as you might loose digits when you use >> "1.0/5.0" - or more obviously "1/5" (= 0). > > Is this true? This is something that has been confusing me for a while. > > While the standard doesn't specify it, the default for real literal > constants on most compilers is single precision.

> >> Is there any way to avoid adding ".0_p" on every single element of the > >> array?

As mentioned above, I more than half suspect it was just a typo, but it still seems like an opportunity for making that point.

glen herrmannsfeldt

> Another suggestion in these situations is to use the shape() > intrinsic to avoid having to specify the dimensions twice. That is, > instead of > real(p) :: ck_a(6,6) = reshape( (/ & > ..., > (/ 6, 6 /) ) > you can have > real(p) :: ck_a(6,6) = reshape( (/ & > ..., > shape(ck_a) ) > Is isn't obvious that this should work, since the dimensions are > declared in the same statement that they are used, but fortunately > things were defined so that it does. In the future, if you ever > need to change the dimensions to, say (6,7), then you would only > need to change that in one place (in addition to adding the new > column of numbers, of course).

> On 4/30/2011 1:12 PM, Daniel Carrera wrote: > > On 04/30/2011 07:47 PM, Richard Maine wrote: > >> So when you write 0_p, that's just like writing 0_8, which has nothing > >> in particular to do with reals. That's just a kind of integer. It might > >> plausibly be a 64-bit integer, or it might be an invalid integer kind. > >> But it certainly is not a real. > > > > I think that's evil.

> How could the syntax possibly be anything else and let one specify > differing KINDs of INTEGERs as well as REALs????????????????

Too late for that one also, as pretty much everyone uses kind value sets that are not disjoint. And far too many people write code that depends on specific kind numbers. That one would not technicaly invalidate any code that was already standard conforming and portable. But it would invalidate an awful lot of code, and it just would not fly. Not even worth seriously proposing.

> Nothing said or implied about good, bad, evil or indifferent as far as > the choice made/adopted, only how the expression has to be interpreted > given what was the adopted syntax.

Oh, sorry. I misunderstood. I was talking about dreams about how things might have been rather than about how things are.

> Fortran has this unfortunate historical baggage of making darn near > everything into integers, even when their current usage has nothing to

>> Compilers could fix this by not reusing any KIND between different >> types, except between REAL and COMPLEX, as required by the standard. >> > > That sounds like a good feature. Even something that I might dream some > day could make its way into the standard.

> Or even if kind values were integers, one could have required that the > kind values for integers and for reals be disjoint sets. The standard > already requires that the compiler be able to diagnose using invalid > kind values, which would apply.

> Too late for that one also, as pretty much everyone uses kind value sets > that are not disjoint. And far too many people write code that depends > on specific kind numbers. That one would not technicaly invalidate any > code that was already standard conforming and portable. But it would > invalidate an awful lot of code, and it just would not fly. Not even > worth seriously proposing.

It would make a nice compiler switch, though. Probably would have to make kind numbers for integer and logical types of the same size the same because there doesn't seem to be a selected_logical_kind intrinsic. Also the switch should guarantee that CHARACTER(C_CHAR) doesn't yield a length-1 string, a sore point for me. Being disjoint from previous values would be nice, too, allowing diagnosis of unportable constructions such as INTEGER(4) MY_HANDLE.

> "Richard Maine" <[email protected]> wrote in message > news:1k0jbxf.1o4vo9hh8rmqN%[email protected]... > > > Or even if kind values were integers, one could have required that the > > kind values for integers and for reals be disjoint sets.

> > But it would > > invalidate an awful lot of code, and it just would not fly. Not even > > worth seriously proposing. > > It would make a nice compiler switch, though.

True. I was referring to it not having a chance at flight in the standard. There already exist compilers with switches to change kind numbering schemes, so it doesn't seem implausible there.

Steve Lionel

> Hmm... I need some module constants that are shared by several > procedures. That's why I had those variables in the module directly.

Refer to http://software.intel.com/en-us/articles/optimization-notice for more information regarding performance and optimization choices in Intel software products.

> > [...] You still need to

> > add the _p for, e.g. 1.0_p/5.0_p as you might loose digits when you use > > "1.0/5.0" - or more obviously "1/5" (= 0). >

Nonetheless I still learned something, so once again thanks for your answers (and patience).

Nope, wasn't me (I even double checked to make sure my memory doesn't fail me). Thanks for your answer though.

Cheers, Daniel.

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a rule for unexpected assignment expression in if, while, dowhile conditionals #152

spmurrayzzz commented Jul 27, 2013

No branches or pull requests

no-multi-assign

Disallows use of chained assignment expressions.

Chaining the assignment of variables can lead to unexpected results and be difficult to read.

Rule Details

This rule disallows using multiple assignments within a single statement.

Examples of incorrect code for this rule:

Examples of correct code for this rule:

This rule has an object option:

• "ignoreNonDeclaration" : When set to true , the rule allows chains that don't include initializing a variable in a declaration or initializing a class field. Default is false .

ignoreNonDeclaration

Examples of correct code for the { "ignoreNonDeclaration": true } option:

Examples of incorrect code for the { "ignoreNonDeclaration": true } option:

Related Rules

• max-statements-per-line

This rule was introduced in ESLint 3.14.0.

• Rule source
• Test source
• Documentation source

TypeScript ESLint: Unsafe assignment of an any value [Fix]

Last updated: Feb 29, 2024 Reading time · 5 min

# TypeScript ESLint: Unsafe assignment of an any value

The error "@typescript-eslint/no-unsafe-assignment: Unsafe assignment of an any value." occurs when you assign a value with a type of any to a variable or a property.

To solve the error, set the variable to a specific type or disable the ESLint rule.

Here are some examples of when the ESLint error is raised.

All of the assignments above cause the error because the ESLint rule prevents you from assigning a value with an any type to a variable.

The any type effectively turns off type checking and should be used sparingly.

This article addresses 2 similar ESLint errors:

• @typescript-eslint/no-unsafe-assignment: Unsafe assignment of an any value.
• Unexpected any. Specify a different type. eslint@typescript-eslint/no-explicit-any

# Disabling the @typescript-eslint/no-unsafe-assignment ESLint rule

One way to get around the ESLint error is to disable the rule.

For example, the following comment disables the rule for 1 line.

If you need to disable the @typescript-eslint/no-explicit-any rule for a single line, use the following comment.

If you need to disable multiple rules for a line, separate them by a comma.

If you need to disable the rule for the entire file, use the following comment.

If you need to disable the @typescript-eslint/no-explicit-any rule for the entire file, use the following comment instead.

You can disable both rules for the entire file by using the following comment.

If you want to disable the rules globally, add the following 2 rules to your .eslintrc.js file.

If you use a .eslintrc.json file, make sure to double-quote the keys and values.

# Setting the variable or property to unknown instead of any

Alternatively, you can set the variable or property to unknown to resolve the ESLint error.

The unknown type is the type-safe counterpart of any .

When working with the unknown type, we basically tell TypeScript that we're going to get this value, but we don't know its type.

We are going to check with a couple of if statements to track the type down and use it safely.

I have written a detailed guide on how to check the type of a variable in TypeScript .

When using the unknown type, you have to use an if statement as a type guard to check the type of the variable before you are able to use any type-specific methods (e.g. string, array, object, etc).

# The error commonly occurs when parsing a JSON string

The error commonly occurs when parsing a JSON string with the JSON.parse() method.

The result variable stores a value of any type because TypeScript doesn't know the type of the value that is being parsed.

One way to resolve the issue is to use a type predicate .

The value is Employee syntax is called a type predicate.

Our function basically checks if the passed-in value is compatible with an object of type Employee .

Notice that in the if block in which we called the isAnEmployee() function, the parsed variable is typed as Employee and we can access the id and name properties without getting TypeScript or ESLint errors.

I've written a detailed guide on how to check if a value is an object .

# Resolve the issue by typing the variable explicitly

You can also resolve the issue by typing the variable explicitly and removing the any type.

Here is an example of typing an object.

And here is an example of typing an array of objects.

You might have to use a type assertion, e.g. when parsing a JSON string.

In some rare cases, you might have to widen the type to unknown before using a type assertion to set a more specific type.

I've written detailed guides on:

• How to initialize a typed Empty Object in TypeScript
• Declare an Empty Array for a typed Variable in TypeScript
• How to add Elements to an Array in TypeScript
• Check if an Array contains a Value in TypeScript
• Check if a Value is an Array (of type) in TypeScript
• How to declare an Array of Objects in TypeScript
• How to declare a Two-dimensional Array in TypeScript
• Declare Array of Numbers, Strings or Booleans in TypeScript
• Create an Object based on an Interface in TypeScript
• Create a Type from an object's Keys or Values in TypeScript
• ESLint: Expected property shorthand object-shorthand [Fixed]
• 'X' should be listed in the project's dependencies, not devDependencies
• ESLint: Unexpected lexical declaration in case block [Fixed]
• ESLint couldn't find the config 'prettier' to extend from
• Import in body of module reorder to top eslint import/first
• ESLint: A form label must be associated with a control

Borislav Hadzhiev

Web Developer

Copyright © 2024 Borislav Hadzhiev

no-unsafe-assignment

Disallow assigning a value with type any to variables and properties.

Extending "plugin:@typescript-eslint/ recommended-type-checked " in an ESLint configuration enables this rule.

This rule requires type information to run.

The any type in TypeScript is a dangerous "escape hatch" from the type system. Using any disables many type checking rules and is generally best used only as a last resort or when prototyping code.

Despite your best intentions, the any type can sometimes leak into your codebase. Assigning an any typed value to a variable can be hard to pick up on, particularly if it leaks in from an external library.

This rule disallows assigning any to a variable, and assigning any[] to an array destructuring.

This rule also compares generic type argument types to ensure you don't pass an unsafe any in a generic position to a receiver that's expecting a specific type. For example, it will error if you assign Set<any> to a variable declared as Set<string> .

Try this rule in the playground ↗

• ❌ Incorrect

There are cases where the rule allows assignment of any to unknown .

Example of any to unknown assignment that are allowed:

This rule is not configurable.

When Not To Use It ​

If your codebase has many existing any s or areas of unsafe code, it may be difficult to enable this rule. It may be easier to skip the no-unsafe-* rules pending increasing type safety in unsafe areas of your project. You might consider using ESLint disable comments for those specific situations instead of completely disabling this rule.

Related To ​

• no-explicit-any
• no-unsafe-argument
• no-unsafe-call
• no-unsafe-member-access
• no-unsafe-return

Resources ​

• Rule source
• Test source
• When Not To Use It

SyntaxError: invalid assignment left-hand side

The JavaScript exception "invalid assignment left-hand side" occurs when there was an unexpected assignment somewhere. It may be triggered when a single = sign was used instead of == or === .

SyntaxError or ReferenceError , depending on the syntax.

What went wrong?

There was an unexpected assignment somewhere. This might be due to a mismatch of an assignment operator and an equality operator , for example. While a single = sign assigns a value to a variable, the == or === operators compare a value.

Typical invalid assignments

In the if statement, you want to use an equality operator ( === ), and for the string concatenation, the plus ( + ) operator is needed.

Assignments producing ReferenceErrors

Invalid assignments don't always produce syntax errors. Sometimes the syntax is almost correct, but at runtime, the left hand side expression evaluates to a value instead of a reference , so the assignment is still invalid. Such errors occur later in execution, when the statement is actually executed.

Function calls, new calls, super() , and this are all values instead of references. If you want to use them on the left hand side, the assignment target needs to be a property of their produced values instead.

Note: In Firefox and Safari, the first example produces a ReferenceError in non-strict mode, and a SyntaxError in strict mode . Chrome throws a runtime ReferenceError for both strict and non-strict modes.

Using optional chaining as assignment target

Optional chaining is not a valid target of assignment.

Instead, you have to first guard the nullish case.

• Assignment operators
• Equality operators

© 2005–2023 MDN contributors. Licensed under the Creative Commons Attribution-ShareAlike License v2.5 or later. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Invalid_assignment_left-hand_side

ReferenceError: invalid assignment left-hand side

The JavaScript exception "invalid assignment left-hand side" occurs when there was an unexpected assignment somewhere. For example, a single " = " sign was used instead of " == " or " === ".

ReferenceError .

What went wrong?

There was an unexpected assignment somewhere. This might be due to a mismatch of a assignment operator and an equality operator , for example. While a single " = " sign assigns a value to a variable, the " == " or " === " operators compare a value.

Typical invalid assignments

In the if statement, you want to use an equality operator ("=="), and for the string concatenation, the plus ("+") operator is needed.

• Assignment operators
• Equality operators

© 2005–2021 MDN contributors. Licensed under the Creative Commons Attribution-ShareAlike License v2.5 or later. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Invalid_assignment_left-hand_side

Error: Unexpected STATEMENT FUNCTION statement at (1)

I’ve taken a very small portion of code from my big program to show the error on the subject line. How do I get rid of this error if most of this code has to stay. DATAX has to be a two dimensional array.

I’m not allowed to use iso_c_binding!

#include <stdio.h> #include <string.h> void test_(char* z1, int leng); int main () { }

I think your entire program should be compiled with -std=legacy .

It appears DATAX is intended to be a rank 2 array, but it is declared as an integer scalar. You need to modify the declaration of DATAX to include bounds. I.e.

Move the statement function data(i,j) = ... above the write(*,*) statement. I’m assuming the write is a remnant of a poor man’s debugging workflow. For more background, check the Oracle documentation on statement functions . Since these are really function-like definitions, they belong in the specification section, before any executable statements like write.

Btw, statement functions have been marked as obsolescent for a while. See Questions about statement functions - #6 by msz59

DATAX cannot be declared an array with bounds I,J if I,J are local variables in the function. Its shape must be defined either by a constant compile-time expression or by expression involving dummy arguments (I assume there are no COMMON blocks in teh code

Here is an example:

Ok, so is datax supposed to be an array or is it supposed to be a statement function? How is it used later in the code? Because if it is supposed to be a statement function, then @ivanpribec is correct, it must appear before any executable statements. If it’s supposed to be an array, then you need to figure out what the actual dimensions are supposed to be. It must be at least as big as i and j ever get if that’s the case. Without more of the actual code, I’m afraid it’s near impossible to tell which is the case.

this was in OP first message, so NOT a statement function

I’m actually leaning towards DATAX is supposed to be a statement function. In that case, I and J are it’s arguments, not used to index into an array. If DATAX is passed as an argument, is the whole thing passed, or is it used like DATAX(1,2) ? The declaration INTEGER DATAX can also mean that DATAX is a function that returns an INTEGER , and so the statement function actually makes sense.

Passed? Where? No trace of DATAX being a dummy argument. It is a total mess.

is F an external function. If so, try declaring it to be external before the write statement.

I notice that G seems to be not declared

Then it is a statement function, and DATAX(1,2) calls it with arguments (1, 2) and passes the result as the actual argument.

That act, by itself, is the major source of error as far as this post is concerned. By taking out essential parts and leaving in inconsequential parts, you have presented code fragments that make no sense.

By presenting different fragments to the compiler, you may cause it to emit a variety of error messages, but most of those messages may have no bearing on the original code.

Consider the C main program that you showed. It has no connection at all to the Fortran subroutine. That C fragment declares an external function called test_, but you did not show the invocation of that function, nor does that name ever occur in the Fortran source lines that you showed.

Well, in that case, the code that you did not show could be something similar to

Related Topics

Secure Your Spot in Our PCA Online Course Starting on April 02 (Click for More Info)

Error: Unexpected ‘,’ or ‘=’ or ‘)’ in R (Examples) | How to Reproduce & Fix

This article shows how to deal with the errors “unexpected ‘,’ or ‘=’ or ‘)’ in X” in R .

The tutorial is structured as follows:

Let’s start right away.

Example 1: Reproduce the Errors – unexpected ‘,’ or ‘=’ or ‘)’ in X

In Example 1, I’ll illustrate how to fix the “unexpected” error when the symbols ‘,’ or ‘=’ or ‘)’ are applied wrong.

Let’s reproduce the errors in R . The following R code leads to the error message “unexpected ‘,’ in ‘,'”…

…the next R syntax leads to the error “unexpected ‘=’ in ‘='”…

…and this R code causes the error message “unexpected ‘)’ in ‘)'”:

In all of these cases the error message occurred because we have not applied the corresponding symbols properly, i.e. we did not add any other R syntax to these symbols.

Example 2: Fix the Errors – unexpected ‘,’ or ‘=’ or ‘)’ in X

The following R programming syntax shows an example how to use the comma symbol properly…

…the next R code uses the equal sign in an appropriate way…

…and this code uses parentheses correctly:

Video, Further Resources & Summary

Have a look at the following video of my YouTube channel. In the video, I’m explaining the R code of this article in a live programming session.

In addition, you might read some of the related articles of this website:

• Handling Errors & Warnings in R (List with Examples)
• R Programming Overview

In summary: You learned in this article how to handle the error messages “unexpected ‘,’ or ‘=’ or ‘)’ in X” in R programming. Let me know in the comments, in case you have additional questions and/or comments.

Subscribe to the Statistics Globe Newsletter

Get regular updates on the latest tutorials, offers & news at Statistics Globe. I hate spam & you may opt out anytime: Privacy Policy .

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Post Comment

I’m Joachim Schork. On this website, I provide statistics tutorials as well as code in Python and R programming.

Statistics Globe Newsletter

Get regular updates on the latest tutorials, offers & news at Statistics Globe. I hate spam & you may opt out anytime: Privacy Policy .

Related Tutorials

Matrix Multiplication Error in R: non-conformable arguments (2 Examples)

R Error in colMeans(x, na.rm = TRUE) : ‘x’ must be numeric (3 Examples)

• | New Account
• | Log In Remember [x]
• | Forgot Password Login: [x]
• Format For Printing
•  -  XML
•  -  Clone This Bug
•  -  Top of page

• Skip to main content
• Skip to search
• Skip to select language
• Sign up for free
• Português (do Brasil)

TypeError: invalid assignment to const "x"

The JavaScript exception "invalid assignment to const" occurs when it was attempted to alter a constant value. JavaScript const declarations can't be re-assigned or redeclared.

What went wrong?

A constant is a value that cannot be altered by the program during normal execution. It cannot change through re-assignment, and it can't be redeclared. In JavaScript, constants are declared using the const keyword.

Invalid redeclaration

Assigning a value to the same constant name in the same block-scope will throw.

Fixing the error

There are multiple options to fix this error. Check what was intended to be achieved with the constant in question.

If you meant to declare another constant, pick another name and re-name. This constant name is already taken in this scope.

const, let or var?

Do not use const if you weren't meaning to declare a constant. Maybe you meant to declare a block-scoped variable with let or global variable with var .

Check if you are in the correct scope. Should this constant appear in this scope or was it meant to appear in a function, for example?

const and immutability

The const declaration creates a read-only reference to a value. It does not mean the value it holds is immutable, just that the variable identifier cannot be reassigned. For instance, in case the content is an object, this means the object itself can still be altered. This means that you can't mutate the value stored in a variable:

But you can mutate the properties in a variable: