ESLint "Unexpected token )" also eclipsing other problems in file - eslint

I'm implementing ESLint along with Prettier in a React project, and the below code is giving a frustrating parsing error.
ReactDOM.render(
<TierComparisonApp {...tier_comparison_app.dataset} />,
document.getElementById('tier_comparison_app'),
); <-- Parsing error: Unexpected token )
Oddly, when I remove the comma after the second argument passed to render, that parsing error goes away, revealing an expected problem in missing that comma, but also another problem with tier_comparision_app being undefined.
ReactDOM.render(
<TierComparisonApp {...tier_comparison_app.dataset} />, <-- (correctly caught as undefined)
document.getElementById('tier_comparison_app') <-- (correctly saying to insert a comma)
);
Stranger yet, making the aforementioned change also reveals problems much earlier in the file having to do with using == instead of ===, which is also expected behavior. Any ideas as to what could be causing this? I've created a Pastebin of my .eslintrc.json because it is a little dense with rules.

So immediately after writing this I realized that I hadn't set my parser to babel-eslint in my .eslintrc.json file, as such:
"parser": "babel-eslint",
Very straightforward solution, and makes total sense as to why ESLint would be encountering a parsing problem. Obviously, you'll need to install babel-eslint with your favorite package manager. I'd recommend this to anyone else running into parsing problems they wouldn't expect, and hopefully me still posting this with an answer can be helpful to someone down the line.

Related

Grunt still unable to handle ES6 imports?

I am working on a project under NodeJS that uses ES6 imports/exports (hence having set type: module in its package.json) and want to automate some tasks using Grunt. Now, I absolutely love grunt, but it appears to me that even in 2022 it is still not able to work nicely with ES6 modules? I always get an error saying "require() of ES Module /vagrant/Gruntfile.js from /vagrant/node_modules/grunt/lib/grunt/task.js not supported."
I understand where this is coming from, and I do understand there are workaround options - in particular, renaming Gruntfile.js to Gruntfile.cjs and passing it to grunt with the --gruntfile command line option. But that is incredibly annoying - it makes the command six times as long as it would be if I could just run grunt and be done with it. Pretty much the same goes for transpiling with something like Babel: That is exactly the kind of thing grunt is intended to handle in the first place, so it feels a bit like the horse riding the jockey. I feel like this should "just work".
Am I missing something here, or is grunt really unable to handle ES6 imports out of the box?
Actually, looking at the grunt github page it appears that a recent commit has addressed it.
I guess this issue will therefore be resolved in their next update.

type GraphQl typegoose backend error while linking models error : Error: Prop-Option "ref"'s value is "null" or "undefined" for "User.projects" [E005]

user schema
projects schema
I've been able to fix it as shown here
however this doesn't seem like the right approach as Its throwing some warnings, also feels very make shift and like Its going to cause some bigger issues in future.
What I want is the cause of the problem and if there is anyother way to fix this
Next time you ask a question, please put the code as code blocks and not as pictures and you should also provide what package versions are used
For this error there is a documentation page, see E005.
In your case it looks like you have a "Circular Dependency" Problem, see Reference other Classes: Circular Dependencies on how to fix this.
The Documentation Page basically says: "put all model compilation (getModelForSchema / buildSchema calls) into one file"

Webpack + TS: Can't make Node.js happy with 'module' or 'commonjs' type

This is my first time setting up Webpack manually, and Typescript is in the mix.
The project builds successfully, but when running the build with yarn start there's the following error:
Error [ERR_REQUIRE_ESM]: require() of ES Module C:\Users\karlo\Projects\reports_server\node_modules\openai\dist\index.js from C:\Users\karlo\Projects\reports_server\dist\server.js not supported.
The error is thrown by this line module.exports = require("openai"); in the output server file. The original .ts files use ES6 imports, but it seems TS or Webpack automatically convert these to CommonJS. Pressing on, let's follow the advice seen online for this error:
Modify package.json to include "type": "module"
Oh boy. Now the following error pops up:
ReferenceError: require is not defined in ES module scope, you can use import instead
That's being thrown by this line: module.exports = require("apollo-server");
The same syntax as the line causing the previous error, and actually just above it in the code.
I'm feeling quite stuck in the middle and kicking myself for not using boilerplate... but at the same time really want to understand where things have gone wrong. If you feel you might know and need more info, please say so.
UPDATE
If anyone has an issue with the openai module in the future, switching to openai-api immediately fixed things. Why exactly openai breaks so spectacularly is still unknown, so this question remains open.

Cargo Clippy throws error 'Question mark operator is useless here' - are suggestions okay to implement?

I've taken over a deploy process and part of this runs Cargo Clippy which was working fine up until late last week, when I started getting this error:
error: Question mark operator is useless here
I've read the suggested link https://rust-lang.github.io/rust-clippy/master/index.html#needless_question_mark
and understand that the ? is no longer required, and have had a look at the suggested changes it offers. I just want to know whether it is okay for me to make the changes as suggested, as some seem to remove some code so I'm not sure whether the result will be the same.
Some of the suggested changes seem to be simple and okay:
From this
Ok(dsl::orgs
.filter(dsl::salesforce_id.eq(salesforce_id))
.get_result(conn)?)
To this:
dsl::orgs
.filter(dsl::salesforce_id.eq(salesforce_id))
.get_result(conn)
So I'm guessing that the above type of change is safe to accept?
Then I have these
Here the 'optional' has disappeared in the suggested fix. From:
Ok(dsl::orgs
.filter(
dsl::customer_id
.eq(new_org.customer_id)
.and(dsl::name.eq(&new_org.name)),
)
.get_result(conn)
.optional()?)
To
dsl::orgs
.filter(
dsl::customer_id
.eq(new_org.customer_id)
.and(dsl::name.eq(&new_org.name)),
)
And this one, where the inner join has disappeared in the suggested fix:
Ok(orgs::dsl::orgs
.filter(orgs::dsl::customer_id.eq(customer_id))
.filter(orgs::dsl::kind.eq(org_kind))
.filter(
orgs::dsl::kind
.eq(OrgKind::Production)
.or(orgs::dsl::name.eq(&org_name)),
)
.inner_join(schema::customers::dsl::customers)
.get_result(conn)?)
to this:
orgs::dsl::orgs
.filter(orgs::dsl::customer_id.eq(customer_id))
.filter(orgs::dsl::kind.eq(org_kind))
.filter(
orgs::dsl::kind
.eq(OrgKind::Production)
Are these 2 suggested fixes okay to implement? Could someone please provide some help?
I've taken over a deploy process and part of this runs Cargo Clippy which was working fine up until late last week,
The lint appeared last week because Rust 1.51 and a new accompanying Clippy version was released last Thursday, and it added needless_question_mark.
when I started getting this error:
Your CI should probably not consider all Clippy lints to be errors. Clippy is designed to give warnings about many things that are simply code style improvements, or possible problems; counting them as errors will lead to unnecessary breakage in the future.
So I'm guessing that the above type of change is safe to accept?
Ok(some_expression?) is almost the same as some_expression. The only difference is that the version with ? may implicitly convert the error type of the expression (the E in Result<T, E>) to the error type expected by the function. If the error types are the same and no conversion is required, then you can remove the Ok and ? and get the same results; if the error types are different, the simplified version will not compile.
Here the 'optional' has disappeared in the suggested fix.
This seems like a bug in Clippy or whatever tool is applying the fix, as the resulting code is semantically different and would not even compile. I'd remove the Ok and ? manually in that case, and report the bug.

why red 'Exclamation Mark' appears on project after installing puppeteer?

Whenever I install puppeteers in my netbeans project, A red Exclamation Mark appears on my project name which is actually representing error in 'install.js' (node Modules/puppeteers/install.js). How to resolve this?
Error
This error is shown as a return statement is normally only expected in functions (but actually also valid outside of them). Therefore, the netbeans syntax checker tells you that this is invalid code (although it is valid).
Most likely, you want Netbeans to ignore the node_modules folder, as bad code inside any of these modules should not be shown as an error in your project.

Resources