I'm having trouble understanding that part of the documentation.
What does eslint mean by "CommonJS global variables"? What those would be?
Related
I'm currently rewriting a NodeJS project from a messy combination of CommonJS and Babel-transpiled ES Modules to be completely ES Module based.
In the process, I've become a bit confused by how Node handles these things. I've tried to read up on it, but I seem to be missing one final piece in my understanding.
I was assuming I would no longer need to use Babel to transpile the ES Modules. This seems to be correct. However, when I run my (Jest) tests, I still need to use the --experimental-vm-modules Node flag to make everything work.
My question is: what does that flag do? Reading the documentation, this seems to enable ES Modules, but didn't I already enable ES Modules by specifying "type": "module" in the package.json file?
Relevant links:
https://nodejs.org/api/esm.html#enabling
https://nodejs.org/api/cli.html#--experimental-vm-modules
https://jestjs.io/docs/ecmascript-modules
Specifying type: "module" in package.json just telling library authors your source code is based on ESM.
For jest, you need to use experimental-vm-modules because the node api jest uses to enable ESM support is still not stable as of node 18.x
https://jestjs.io/docs/ecmascript-modules
I've tried many things to solve this issue. I'm trying to import from absolute paths defined on my tsconfig.json
on a file on my project I'm trying to use import { UserModel } from "model/User";
And on my tsconfig.json I have
{
....
"baseUrl": "src",
"paths": {
"model/*": ["model/*"]`
}
....
}
I've tried changing the baseUrl to ".", "./" and changing the paths as well, but I'm always getting the same error:
Error: Cannot find module 'model/User'
I have also tried to add an index.ts file to the model folder and export models from there, but still.. same issue. Any help is appreciated.
If you are writing a package, then probably you are reserved to using the ttypescript lib + #zerollup/ts-transform-paths plugin - those will do the job. Also, building your package will have to use ttsc instead of tsc.
If, on the other hand, you are using a bundler to bundle your code together (like webpack), you will have to reserve to the ways provided by the bunder's config.
Also, if you are using ESLint, you'll have to make sure it uses tsconfig.json via eslint-import-resolver-typescript npm package.
Also, if you are using Jest for unit-tests, you will have to enumerate the possible "roots" like this:
moduleDirectories: ['node_modules', 'src'],
I've set up a new nodeJS project with typescript. My linter is flagging me with errors, for example:
import authentication from "./routes/authentication"; // Flags "Cannot find module ..."
I would like it to flag a warning/error for these statements, as they break my app when I try to load it:
const pool = require("../database/db"); // Currently not flagging as a warning either for the fact that the file does not exist, or that it is using a require() statement.
I'm guessing eslint is doing my linting. But I haven't explicitly set it up. I tried creating and playing with a .eslint.rc file, but nothing happened.
How do I check what my linter is? I can't find anything in my VS-Code settings to say what I'm using. I can't find any reference to it in my package.json or tsconfig.json files that reference a linter either?
How do I then get my linter to flag require() statements?
So it looks like eslint was already running. It was installed in my extensions, but I've no idea what rules it was using. It must have been some defaults?
I ran yarn add eslint -D and npx eslint --init to set up eslint. Then I changed the rules: object in my .eslintrc.js file. This seems to have changed the linting, which suggests I was already using eslint.
I haven't yet worked out how to flag errors for the require() statements. I've found this YouTube video, which explains that:
require() statements are just functions. We can write require() statements within if() conditions and functions. This is not possible with import ... from ... statements
Because require() statements are functions, they are only being called in runtime. imports are static, so they are being checked by typescript in parse time. This is useful as it means we can get errors before moving into runtime.
I never found a better way of checking what linter my VS-Code was running other than setting up eslint with the github.com/typescript-eslint/... instructions and then playing with the .eslintrc.js file to see that the rules changed. Even then I had to runyarn eslint . --ext .js,.jsx,.ts,.tsx before the rules:{} in my .eslintrc.js started to take effect.
In order to get the require() statements to flag up with my linter, I added the following to my .eslintrc.js rules:{} property:
rules: {
"#typescript-eslint/no-var-requires": 1,
...
}
Although this didn't take effect until after I'd followed the steps described in item 1. As stated above, for some reason I had to run yarn eslint . --ext .js,.jsx,.ts,.tsx before the rules:{} in my .eslintrc.js started to take effect.
I have the following problem and know exactly why it has been triggered, but I haven't found any solution yet, so probably the community may help me with that.
I am using tsdx for initiating ts repos, and also ts-node for quick debug (instead of building code each time).
Recursive Dilemma:
So, each time when I want to add the module to my package via yarn add modulename and if in my tsconfig.json file in compilerOptions option: "module": "commonjs" has the following value, tsdx build unable to build code, and return me the following error:
Error: Incompatible tsconfig option. Module resolves to 'CommonJS'. This is incompatible with rollup, please use 'module: "ES2015"' or 'module: "ESNext"'
BUT!
if I will update compilerOptions to module: "ESNext" from commonjs, ts-node will give me an error, because it's still unable to use import {Method} from Module instead of const x = require(CommonJS) (which is quite old bug, according to this issue and this question)
Typescript -v 4.1.5 (latest)
ts-node: "^9.1.1"
node -v: 15+
"compilerOptions": {
"module": "commonjs", || "ESNext"
"lib": ["dom", "esnext"],
...//other options
According to that, I am using WebStorm and README.md from ts-node repo, I understand, that I could update Environment Variables with custom tsconfig. So in that case I need two tsconfig files in repo, for ts-node and for production. So the question is: maybe there is another TS_NODE_FLAG, especially for module compiler options? So I could run ts-node with the flag, that would overwrite this minor parameter?
Currently working compromise is having two config files, which are exactly the same:
tsconfig.json
tsconfig.dev.json
except that the second has "module":"commonjs"
The second option, which actually somehow not working for me is adding to WebStrom's Environment Variables TS_NODE_COMPILER_OPTIONS='{"module":"commonjs"}' from this question.
another option:
import typescript from 'rollup-plugin-typescript2';
export default {
...
plugins: [
typescript({
// 覆盖 tsconfig.json 的配置项
tsconfigOverride: {
compilerOptions: {
module: "ESNext"
},
include: ['src/**/*'],
},
})
]
};
I am trying to import some types from #types/webgl2 in my project.
I have followed every bit of advice mentioned here:
TypeScript typings give me "index.d.ts is not a module"
Added this to the top: import 'webgl2';
I have made sure "modeResolution" is "true" in tsconfig.json
I added a line "types":["webgl2"] to my tsconfig.json
Added "#types/webgl2": "0.0.4" to both devDependencies and dependencies in package.json.
Did an npm install in my project folder:
npm WARN package.json webgl#0.0.1 No README data
npm WARN package.json Dependency '#types/webgl2' exists in both dependencies and devDependencies, using '#types/webgl2#0.0.4' from dependencies
I can easily see webgl2 in node_modules/#types and I can also see the declaration for all errored symbols under:
declare var WebGl2RenderingContext {
and I still get these errors:
(multiple lines)
Cannot find name 'WebGl2RenderingContext'. Did you mean 'WebGL2RenderingContext'?
Corresoonding to:
const format = WebGl2RenderingContext.RED;
Resolved by fixing spelling mistakes.
In your tsconfig set the typeRoot:
{
"typeRoots": ["node_modules/#types"]
}
For NG9'ers, try, deleting your package-lock.json file, then:
npm i crypto
For me, I had an issue where types was specified in tsconfig so some types weren't automatically added to the global scope.
So the package in question was #types/dom-webcodecs and I added this to tsconfig like this
{
"compilerOptions": {
"types": [
"dom-webcodecs",
...
]
}
}
and after that I could access the types.
This is different than typeRoots which another answer talks about. You can explore the difference here if need be.