eclipse-thingweb / td-tools

Utility libraries for W3C Thing Descriptions and Thing Models
https://thingweb.io
Other
4 stars 3 forks source link

`.eslintrc.js` Usage #46

Open egekorkan opened 3 months ago

egekorkan commented 3 months ago

I checked and we do not have an .eslintrc.js. We have .eslintrc.json which serves another purpose. Shall we do it in a follow-up issue/PR because I think we will see many other changes also.

Originally posted by @danielpeintner in https://github.com/eclipse-thingweb/td-tools/issues/34#issuecomment-2228029964

egekorkan commented 3 months ago

@danielpeintner could you integrate that?

danielpeintner commented 3 months ago

I quickly checked and I am no longer sure about the difference between the two files...

node-wot has .eslintrc.js while td-tools has .eslintrc.json @egekorkan you created it initially ..

JKRhb commented 3 months ago

Hmm, I think .eslintrc.js is just a JS-based version of .eslintrc.json, so just a different format for the same configuration options.

egekorkan commented 3 months ago

Reading up on this from here, js version is simply more feature rich due to being a program in the first place. I think we should simply take the js version everywhere where we have a common section. Each repo can then extend it as needed.

I have created the json version without thinking too much and would be happy to make this change. Any opinions?

JKRhb commented 3 months ago

Reading up on this from here, js version is simply more feature rich due to being a program in the first place. I think we should simply take the js version everywhere where we have a common section. Each repo can then extend it as needed.

I think these are very good reasons for making a switch to the JS variant :)

I have created the json version without thinking too much and would be happy to make this change.

That would be great!

It seems that using the JS variant could also enable us to create a reusable base config that we could refer to via package.json and then extend if needed. Maybe that is a bit overkill at this point, but if we have more packages in the future, that could be something to consider to have a consistent configuration across all Thingweb repositories.