To Fix the Issue, We Need to First Understand the Issue.

The error message you received was from the parser. Which output the following:

1:1  error  Parsing error: Octal literal in strict mode
> 39 |  language.french.value           = ' caract\350res';

When error messages are implemented correctly they are a great resource for sniffing out the root causes of difficult errors. The error message above is not the most verbose error message, but it hits the nail on the head — the message has 2 pertinent pieces of information that should be noted.

  1. Its a Parsing error, meaning an error occurred while a parser was parsing the JS file.

  2. and, the second is that the error occurred because an Octal literal was located in a script that is being ran in strict mode.

Put it together, and it becomes clear. The parser threw an error because there is an octal being used in a script that is ran in strict mode.

I think its obvious from the error message, but if you haven't realized it, Octal's are not allowed in strict mode. With or with out ESLint this is true. Just FYI.

The Problem is Not Strict-Mode — the Problem is the Module-Type

Contemporary ECMAScripts have implemented something called ES-Modules, or ESM. They are Very cool but I am not going to explain what they are further than they are a ECMAS supported module, something that is relatively new to front-end JS. Node on the other hand has had modules for a long time, how ever Node.js Modules are not Standard ECMAS JavaScript. With node, you can now create, ESM modules, or CJS modules.


How does any of this have to do with our problem?


Well because 'use strict';, or Strict Mode is the ESM standard, and all ES Modules are parsed in strict mode, and therefore; some of the non-strict constructs, like the octal literal above, will cause parsing errors when ESLint parses modules that are type: ESM. Modules that are type CJS, or Common-JS Modules, often depend on those 'strict-mode illegal constructs` (like the octal literals), and if you depend on them your bundle will blow up. There's nothing we can do about that.

Its important moving forward to configure your ESLint parser to parse the correct type of module:

// Using the babel parser you would do this

// @file ".eslintrc(.?)"
      "parser": "@babel/eslint-parser",
      "parserOptions": {
        "sourceType": "script"

The module types are often defined as Scripts or Modules, this is because as far as ECMAS is concerned, a JavaScript file is either a Standard JS Script, or a ESM Module. You should also configure your package.json file if your using one.

  // @file "package.json"

      type: module /* or script */


I've just run into the same issue, finally found an answer on github. You can turn off the global strict mode by changing the sourceType to script within your .eslintrc file:

  parser: 'babel-eslint',
  parserOptions: {
    sourceType: 'script'

Or, if you want to set this through the cli then simply:

eslint --no-eslintrc --parser=babel-eslint --parser-options=sourceType:script file.js

Related Query

More Query from same tag