Some questions about this project

[asamuzaK]

I am very excited to find this project of yours.
If there is anything I can do to help, I would love to.

I have a few questions.

• Why commonjs?
  This project targets Node.js v20 and above, I don't see much benefit in maintaining the project in commonjs at this time.
• Do you envision replacing rrweb-cssom and cssstyle that jsdom depends on as one of the goals of this project?
• Also about coding styles.
  For example, four spaces, no semicolons, and other styles that are not very popular these days, do you think these coding styles could be changed?

Thanks

[cdoublev]

Yes, this library is clearly intended for use in jsdom, which operates on CommonJS modules.

As noted in jsdom/cssstyle#140, I started it over 2 years ago. As CSS was evolving at a rapid pace, as I struggled to get a strictly conforming implementation for some parts, as no one showed any interest in it, etc... I kept developing it quietly.

I only saw yesterday that cssstyle received a few updates since last year. Maybe I should not have been so quiet.

Anyway, it is now almost ready. I am satisfied with the "core" processing model. The goal was to make adding support for a new syntax easier for any newcomer. There are many pending issues I have created on the CSSWG repository that would require changes here, but jsdom users probably do not care about the specific problems these issues are about.

do you think these coding styles could be changed?

Sure, but not for semicolons or the number of spaces. I do not care about the style of the code, only its clarity, then its consistency at a much lesser degree.

I would like to move this repository under the umbrella of jsdom, and become a "simple" contributor, ideally. But at the end of the say, a maintainer has to make decisions.

If I have to be that maintainer...

I do not mind enforcing semicolons but I think good developers should know the language they use and where these semicolons are actually needed. That is an opinion. Forcing people to have the same opinion is not good, no matter what the context. Diversity is a strength.

If a coding style rule can help increasing clarity, I would welcome it.

[asamuzaK]

Thanks for your quick and detailed answer.

Yes, this library is clearly intended for use in jsdom, which operates on CommonJS modules.

Got it.

The goal was to make adding support for a new syntax easier for any newcomer.

Great, I'm glad to hear that.

Sure, but not for semicolons or the number of spaces. I do not care about the style of the code, only its clarity, then its consistency at a much lesser degree.

Fine with me.
However, I would like to suggest adding the --fix option to eslint.
That way, other users and contributors don't have to worry about code style either.

"lint": "eslint . --fix",

And one thing I would like to tell you is that there are side effects if you don't use semicolons.
For example, save below and run node semi.js.

semi.js:

function func() {
  return [];
}

console.log('with semicolon');
let test;
console.log('expect: undefined, actual: ', test);
func();
[test] = [true];
console.log('expect: true, actual: ', test);
[test] = [true];
console.log('expect: true, actual: ', test);

console.log('without semicolon')
let test2
console.log('expect: undefined, actual: ', test2)
func()
[test2] = [true]
console.log('expect: true, actual: ', test2)
[test2] = [true]
console.log('expect: true, actual: ', test2)

Anyway, I would like to see if there is anything I can contribute to this project.

[asamuzaK]

Since the question has been answered, I will close the issue.