0

An eslint rule no-var-requires in a recent project forces me to write import = require(). I have never seen this until now and I never had any issues with importing, but reading about it reveals that this was a thing in 2017 already. This makes me wonder why would anyone enforce this - or better, why is it considered a bad practice to use require() and what is the actual difference between

export default class ZipCodeValidator { }

export = class ZipCodeValidator { }

where the latter is, in my understanding, directly connected to the import = require() syntax in TS?

The documentation about export = and import = require()^ says that

Both CommonJS and AMD support replacing the exports object with a custom single object. Default exports are meant to act as a replacement for this behavior; however, the two are incompatible.

But all these work just fine

require('dotenv').config() // this is what I used originally

import dotenv = require('dotenv') // the eslint rule forces me to write this
dotenv.config()

const dotenv = require('dotenv')
dotenv.config()

import * as dotenv from 'dotenv' // This is what I've been using otherwise
dotenv.config()

This makes me wonder about the purpose of import = require() in the first place.

Instead of just using the sleek unobtrusive require with a call in one line, it forces me to split the importing and invocation in two lines, which in turn brings another complication. We have a lint/prettier rule to organize imports to the top, but this makes the other imported modules run BEFORE my environment is initialized.

Forgive me for asking in such vague manner, but I don't even know where to start.

Qwerty
  • 29,062
  • 22
  • 108
  • 136
  • Does this answer your question? [The difference between "require(x)" and "import x"](https://stackoverflow.com/questions/46677752/the-difference-between-requirex-and-import-x) – Etheryte May 25 '21 at 13:33
  • @Etheryte No, thank you. I should have linked this question in my question. – Qwerty May 25 '21 at 13:34
  • This gets close, but it is not answered either [Import and require used together](https://stackoverflow.com/questions/42250682/import-and-require-used-together) – Qwerty May 25 '21 at 13:44
  • The number of man hours lost to trying to cram things into one line is staggeringly high, and moderately depressing. But that's besides the point. The top of your question asks for the difference between `export default` and `export =`, but the remainder talks a lot about `import =`. But the rule discussed, `no-var-requires`, only talks about `var/let/const variable = require(...);` vs `import variable = require(...);` (three more characters, hardly "bloated"), `require(...)` (only useful in some circumstances), or `import variable from '...'` which appears to be roughly the same char count. – Heretic Monkey May 25 '21 at 13:45
  • @HereticMonkey having to split import and invocation makes the other imported modules be executed before the environment is initialized (in the case of `dotenv`) because other imports get organized at the top. Being able to import/run it on the same line is therefore very necessary. Obviously, this was never about the number of characters typed, but about the two lines vs one and the non-cosmetic implications. – Qwerty May 25 '21 at 13:53
  • So... Do you need to know the difference between `export default` and `export =` or why `var variable = require(...)` has an ESLint rule against it? – Heretic Monkey May 25 '21 at 14:35
  • @HereticMonkey I restructured my question. Hopefully it is more consistent now. – Qwerty May 25 '21 at 14:45

0 Answers0