Skip to content

Backward compatibility for pre ES2021#8

Open
manuelguzmandao wants to merge 3 commits intoso-ric:masterfrom
manuelguzmandao:pre-ES2021-compatibility
Open

Backward compatibility for pre ES2021#8
manuelguzmandao wants to merge 3 commits intoso-ric:masterfrom
manuelguzmandao:pre-ES2021-compatibility

Conversation

@manuelguzmandao
Copy link

The objective is to make this module compatible with old code using pre ES2021. For example, winston3.3.3 depending on @dabh/diagnostics@^2 which pulls this module. (winstonjs/winston#2586)

manuelguzmandao and others added 3 commits October 8, 2025 23:15
The objective is to make this module compatible with old code using pre ES2021. For example, winston3.3.3 depending on @dabh/diagnostics@^2 which pulls this module. (winstonjs/winston#2586)
@IamLizu
Copy link

IamLizu commented Oct 10, 2025

Appreciate the effort @manuelguzmandao

Node 14 (14.21.3) works with the patch mentioned in winstonjs/winston#2586 (comment)

That said, change diff looks large, haven't take a look at it yet, but are there formatting changes?

@manuelguzmandao
Copy link
Author

@IamLizu I just added to the rollup a step to transpile the file dist/index.cjs.js to Node 14 compatible syntax. That "dist" file is a generated file, patching it directly will not work as in the future, if a change is made in the source code and the rollup done again, all changes will be lost. As you mentioned, most of the changes in dist/index.cjs.js are formatting changes, but that is what the transpilation did. Real changes are equivalent to what you mentioned in winstonjs/winston#2586 (comment)

@IamLizu
Copy link

IamLizu commented Oct 10, 2025

I am generally +1 on this, but will take a look at this later tonight or tomorrow morning.

@hanzhangyu
Copy link

Any updates? 👀

@snehahaldankar
Copy link

Any updates? Will this fix work for Node 12 as well?

@leah-dotcom
Copy link

Any updates? When will this fix be merged?

@t3nowe
Copy link

t3nowe commented Oct 16, 2025

+1

@KaliLinuxF
Copy link

+1. got same problem with nodejs14.

@NikaKondr
Copy link

+1

@takedabruno
Copy link

I had this same problem with NodeJS 14 and figured out why.

The current version of @so-ric/colorspace uses a dependency called colors@5.0.2, which is compatible with >=NodeJS 18.

So, the transpiled version of @so-ric/colorspace incorporates a "||=" operator in the code, which makes it unworkable for NodeJS <15.

I had problems with Winston@>3.3.x (which uses the dependency). The solution was to use winston@3.0.0, which is compatible with NodeJS 14.

My suggestion to the author of @so-ric/colorspace is to add the "engines": {"node": ">=15"} parameter to package.json or use colors@4.x.x.

@psigourney
Copy link

psigourney commented Nov 6, 2025

I had this same problem with NodeJS 14 and figured out why.

The current version of @so-ric/colorspace uses a dependency called colors@5.0.2, which is compatible with >=NodeJS 18.

My suggestion to the author of @so-ric/colorspace is to add the "engines": {"node": ">=15"} parameter to package.json or use colors@4.x.x.

Same here. I came to this repo to try to find the nodejs version requirements in order to resolve the runtime errors and couldn't find anything.

Just adding a "requires nodejs 18 or you'll get this runtime error" line in the README would be a huge help.

Considering the whole purpose of the @so-ric/colorspace package (over the base colorspace package) is to remediate security vulnerabilities, it makes more sense to require developers to update their apps to use a recent node framework versions rather than patching this package to allow devs to continue building apps on EOL versions of node.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants