New issue
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
Allow for dynamic import() to be used in eslint config file #13684
Comments
Hi @KilianKilmister, thanks for the issue! Could you please share an example of a config file with dynamic imports? Does it work when you set the env-variable |
i've had issues properly reproducing it with a simpler loader. this is a slight modification of the one i used originally. it was supposed to load a merge a directory of sub-configs. Trying to load this normaly does throw Using I have very little experience with CommonJs, so i can't make much of a statement around why the loading isn't working this way. From the issue field in
It's using the nodejs // .eslintrc.cjs
(async () => {
const entries = []
entries.push(await import('./test.js'))
module.exports = {
...entries.map(dissector).reduce(reducer, {}),
root: true
}
})()
function dissector (item, index) {
return Object.entries(item)
}
/**
*
* @param {{[key: string]: unknown}} prev
* @param {[string, any]} curr
*/
function reducer (prev, [key, value]) {
if (!(key in prev)) prev[key] = value
else prev[key] = {
...prev[key], ...value
}
return prev
} // test.js
export default {
rules: {
camelcase: 'error'
}
} |
This won't work as expected. Requiring For example: //----- a.js -----
(async () => {
module.exports = await { foo: "bar" };
})(); //----- b.js -----
console.log(require("./a")); // logs {} The assignment to //----- b.js -----
console.log(require("./a")); // logs {}
setTimeout(() => console.log(require("./a"))); // logs { foo: 'bar' } Unfortunately, I don't think it's possible to have an async config with the current eslint config system, so I believe there's no way to use dynamic imports in eslint config files at the moment, regardless of the |
@mdjermanovic thanks for the explanation. I somewhat expected this not to work. But i wasn't sure as i avoid CommonJS whenever it's possible. Should this be kept open for the |
This isn't a problem at the moment, since it doesn't seem possible to use But, |
I’ll keep an eye out as I go. Node.js ESM support is still considered experimental, so definitely worth following up with them about this issue. |
Unfortunately, it looks like there wasn't enough interest from the team Thanks for contributing to ESLint and we appreciate your understanding. |
Here's how to import ES Modules in a synchronous way: const deasync = require('deasync'); // powerful magic
const promiseSync = deasync((promise, cb) => {
promise.then((result) => cb(null, result)).catch((error) => cb(error));
});
const importSync = (name) => promiseSync(import(name));
// Look, no await needed here!
const something = importSync('./something.js').default;
module.exports = {
...something,
// ...
} See Running with |
Awesome, thanks for sharing this! |
The version of ESLint you are using.
ESLint-v7.8.1
The problem you want to solve.
Currently, while eslint understands the meaning of the
.cjs
extension, it is unable to load a config file that uses dinamicimport()
statements. It fails with an error:This is caused by the dependency
v8-compile-cache
which patches the node internalModule.prototype._compile
method in an insufficient fashion.The purpouse of solving this is easier handeling of eslint configs for esm-users until
config-file-simplification
arrives (RFC). The Roadmap estimated the implementation to arrive in 5 months (6 months when the statement was made).Your take on the correct solution to problem.
As the problem is caused by a dependency, there is no straight forward solution.
I'll file an issue in in the project after i'm done here.issue filedNOTE: While debugging the issue, I found some things that are potential road-blocks for esm support (like the dependency
import-fresh
, which dispite the name is for loading cjs). I'll be doing some more exploring and will post a proper report (propaby in the RFC repo) once i have some spare time.Are you willing to submit a pull request to implement this change?
Potentially. I'll check what exactly would need to have to change in
v8-compile-cache
and possibly make a PR there to solve the problem at the root. Besides that, it depends on what I find while examining the things mentioned in the note.NOTE: A quick-fix is setting the env-variable
DISABLE_V8_COMPILE_CACHE
The text was updated successfully, but these errors were encountered: