16.6.2: can n/no-missing-require allow resolvePaths ['./'] for relative imports?

[lkraav]

Environment

Node version: 16.20.2
npm version: 8
ESLint version: 8.57
eslint-plugin-n version: 16.6.2
Operating System: Linux

What rule do you want to report?

n/no-missing-require

Link to Minimal Reproducible Example

What did you expect to happen?

const config = require('config'); is getting flagged for n/no-missing-require, even though config/ module directory is living next to the source file.

(I'll try following up with a stackblitz example if this is unclear.)

Participation

• I am willing to submit a pull request for this issue.

Additional comments

Am I missing something obvious for why below doesn't help

  rules: {
    'n/no-missing-require': ['error', {
      'resolvePaths': ['./'],
    }],
  },

I'm not against refactoring everything to explicit require('./config'), but would like to allow sibling requires until we get it done. Is this possible?

PS not a "bug" I think, but Discussions isn't enabled on this repo.

[scagood]

Where would it resolve the ./ from? do you think it should be resolved from the eslint cwd options?

By the time the plugin gets the setting we dont really know where the config file was 🤔

[lkraav]

Where would it resolve the ./ from? do you think it should be resolved from the eslint cwd options?

By the time the plugin gets the setting we dont really know where the config file was 🤔

Yes, I had the same question. In my naive mind, relative resolvePaths would resolve in a JIT manner, so calculated on each specific target file.

But maybe this is a bug, after all, and subject to codebase update? Maybe n/no-missing-require should simply not trigger on requiring any file's sibling modules? Because everything else seems to recognize such as valid, or at the very least, definitey not "not found".

[scagood]

Can you provide a small example of where this applies?

I have setup a small starting point for you here: https://eslint-online-playground.netlify.app/#eNpNkL1 Once you have the error there, can you paste the url here?

[lkraav]

Can you provide a small example of where this applies?

I have setup a small starting point for you here

Thanks, check https://eslint-online-playground.netlify.app/#eNp1kL1SxSAQhV8FaaIzN0kfWws7OxuxwGTDoLAgP05m7uTdXSCOaW5Dcc53OLt75THMI2zSegPDZ+QTD/CddYB7wYcxyaAgCf7wKPBfnx2uWhWVX2q+YS1OZnT0l3GK0Gcwxt2d0JYdNS6w3QywRv3lIBqNaWjiYGtKW+9CYsjW4CwTB9N7k5XGHgUXKBC2Ci2wymwSe2NXUpORqLJU8OKTpu6pqSLBbOUrhEjixDojE8TUXZqnjPuQprDsuMPEUsjA9gq0t5VXCA8jZAO1geOIrrc6Ro2qP/4QnIogBBe6gu/snbb1cv6i6eg4DmlRGo7Rfgv8PIEHOhvOGmJJVqd4bfciCd7GFpy+O5unw5ypAu1UzPdftvu0bQ==

require("config"); in my mind should not trigger "config" is not found in example.js.

[scagood]

I am not sure if that is a valid resolution?

Are you using a special library that resolves these?

I would expect that resolution to be written like: ./config, ./config/index, or ./config/index js

[lkraav]

We have jsconfig.json files involved, I wonder if these are having an actual effect here

{
  "compilerOptions": {
    "baseUrl": "./src/",
    "module": "nodenext",
    "paths": {
      "*": ["./*"],
      "lib/*": ["../../../packages/lib/server/*"]
    }
  }
}

That first wildcard may be the one doing the trick? 🤔

[scagood]

mmm, so this is a request to support jsconfig.json, like we do for the tsconfig.json

https://github.com/eslint-community/eslint-plugin-n/blob/master/lib/util/import-target.js#L272-L275

[lkraav]

mmm, so this is a request to support jsconfig.json, like we do for the tsconfig.json

Booyah, you are probably right. Is this a fairly light lift to try a test PR, considering tsconfig support already exists, and afaik they're fairly similar?

[aladdin-add]

just a reminder: you can use tsconfig.json + "allowJs": true. :)

[lkraav]

just a reminder: you can use tsconfig.json + "allowJs": true. :)

Interesting idea. Is this a 100% drop-in change, even with no other TS tooling installed yet?

TS is on the roadmap in the coming month, so I wouldn't be opposed to making this rename move early, if it's without side-effects 🤔

[scagood]

It looks to be, but I am not completely sure 👀

https://code.visualstudio.com/docs/languages/jsconfig

[lkraav]

It looks to be, but I am not completely sure 👀

Tip: jsconfig.json is a descendant of tsconfig.json, which is a configuration file for TypeScript. jsconfig.json is tsconfig.json with "allowJs" attribute set to true.

Thanks for reminding me of the docs link, above paragraph definitely looks tasty enough to try right away.

[lkraav]

I don't see going to tsconfig.json having helped

{
  "compilerOptions": {
    "allowJs": true,
    "baseUrl": "./src/",
    "module": "nodenext",
    "paths": {
      "*": ["./*"],
      "lib/*": ["../../../packages/lib/server/*"]
    }
  }
}

still gives me

[leho:project.git] demo(+0/-8,3)+* ± eslint apps/api/src/resources/test/test.service.js

/home/leho/Documents/project.git/apps/api/src/resources/test/test.service.js
    1:24  error  "config" is not found                                                 n/no-missing-require

[lkraav]

Playground example https://eslint-online-playground.netlify.app/#eNp1UU1TwyAQ/SvIJeqY5l6vHhwvnvRSeqDJFlFYEIh2ppP/7gJpjTrOZAi89/bj7R55DH0HB2m9gdVr5Gse4H3UAS4FX3VJBgVJ8Ktbgd9473CvVUb5TYmvshpOZHSUyzhF0nswxl0spDW20zjA4d8AVlWnuBTrm/QOKeIokLHchvXaQHj0SVMOwdesMJmTlOXzoWApjHBzwncywlMwGc/+ckeCn1nrhtFAJdENgHAg82fay/SyLJOx6/ze5Fx021Z8yj866KPuIRqNaTVbsMWztt6FxJDtg7OUpWpab0alsUXBBQoqXkQD7OVoEtvksiIZiWqUCmbXpRmRRILeymcIkcA1a4xMEFNDrWdOGbeTJmvZvMU6FjYVQT1r8SLCmQg0jVKBY4eutTpGjaqdc2TnDYTgQpPlE9uSWy/7N+ru16oG+LgDD7R07DX8XFX1Xode216M/M9glqrTmPn0BZX67aE=

[lkraav]

And another roadblock: #139 for TS only appeared in v17, but we're still on Node 16, so stuck on v16 right now. PR seemed fairly large, is there even a chance of it applying for a backport?

[aladdin-add]

It's not possible as it's a breaking change. and we will release v17(latest) soon then the v16 is going to be EOL.

[scagood]

@ikraav Is this still an issue? v17 has been released with the tsconfig support 😁

[lkraav]

@ikraav Is this still an issue? v17 has been released with the tsconfig support 😁

It remains an issue, because we can't easily upgrade our app from Node 16 -> 20, too many things break, so it becomes a project.

Do I understand correctly there's no low-lift way to backport tsconfig compatibility? If not, it's a bit of a limbo situation.

[scagood]

I am going to be closing this, if you have issues after you update please create another issue 👀