Rule proposal: no-dir-import

[IvanGoncharov]

We plan to support ESM modules for the next release of graphql-js and as part of this effort, we need to have full paths inside imports.
I tried to switch to full paths and enable extensions rule, but this created a lot of problems with different tooling, so our current approach is to have full paths but without extensions.
It means we need to add /index to all directory imports see this PR for more details:
graphql/graphql-js#2368

Additionally, I wrote custom ESLint rule to enforce this approach:
https://github.com/graphql/graphql-js/blob/master/resources/eslint-rules/no-dir-import.js

I think other maintainers will have similar challenges trying to release ESM build, so do you think it something that should be included in this plugin?

P.S. At the moment I don't have time to polish this rule (add docs and tests), so if anyone wants to work on PR, please feel free to reuse code that I wrote for graphql-js:
https://github.com/graphql/graphql-js/blob/master/resources/eslint-rules/no-dir-import.js

[ljharb]

You don't actually have to have full paths (ie, relative paths with index/extensions) inside imports - you can also use "exports" and the package name and define your own API.

You can already make extensions required for mjs files; if the only remaining piece is import, then you should be able to this option with "overrides", to solely apply to mjs files?

[IvanGoncharov]

@laysent Thanks for the quick reply 👍

You don't actually have to have full paths (ie, relative paths with index/extensions) inside imports - you can also use "exports" and the package name and define your own API.

I can't since the main goal is to allow graphql.js usage in "buildstep-less architectures on the web" (as described in graphql/graphql-js#2277) and also to make it compatible with Deno.

So we can't use "exports" since it's purely Node.js feature and ignored both by the browser and by Deno.

You can already make extensions required for mjs files; if the only remaining piece is import, then you should be able to this option with "overrides", to solely apply to mjs files?

We are migrating from Flow to TS so we can't use mjs extensions and need to transpile files.
Also for every source file, we need to release foo.js(CJS), foo.mjs, foo.d.ts, foo.flow.js and typing files can't use extensions (at least in *.d.ts).

So the simplest solution is to add babel plugin add .mjs to every import in *.mjs files:
https://github.com/graphql/graphql-js/blob/master/resources/add-extension-to-import-paths.js

[ljharb]

imo it's unrealistic to expect a node package to be compatible out of the box with browsers or with deno, and also imo unrealistic to ever have no build process in web dev; either way you should have different files for use in different platforms.

You can use .js extensions in node for ESM if you add "type": "module" to your package.json, and use .cjs for CJS files, and then configure eslint that way.

[IvanGoncharov]

imo it's unrealistic to expect a node package to be compatible out of the box with browsers or with deno, and also imo unrealistic to ever have no build process in web dev; either way you should have different files for use in different platforms.

@ljharb If a library has zero dependencies (or you bundle them during build) and doesn't use anything beyond core JS than it's possible.
For example lodash and prettier (lib not a CLI) both compatible with Deno.
There is a growing number of such packages: https://deno.land/x/

You can use .js extensions in node for ESM if you add "type": "module" to your package.json

I can't since Node 10 is still in LTS and AFAIK it doesn't support "type": "module".

[ljharb]

That's a lot of caveats and inconvenience to make something that's not even objectively desirable, possible.

That's true, at the moment only node v13.2+ supports it. Why can't you use .mjs with Flow and/or TS?

[IvanGoncharov]

Why can't you use .mjs with Flow and/or TS?

@ljharb TS forbids you to have extensions at all:

An import path cannot end with a '.ts' extension. Consider importing './version' instead.

[ljharb]

Seems like something TS will have to change, to account for node's experimental but native ESM module system.