You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An npm install of node-red-nodegen results in 265Mb of node_modules. If you npm install the repository (so devDependencies are included) it's over 650Mb.
I would like to see if we can reduce this overhead. This issue is a summary of what is using the space - and to explore what we can do about it.
Here are the current dependencies and how much they contribute to node_modules:
Size
Module
40
js-string-escape
128
csv-string
184
colors
192
minimist
320
mustache
1040
axios
2720
yamljs
3736
ajv
31008
swagger-js-codegen-formdata
51464
javascript-obfuscator
76464
jimp
200344
api-spec-converter
405144
cldr
The main offender is cldr (198Mb) - which is used by the WoT node to determine the text direction of some part of text. I don't know enough about the WoT code to know how important this is and whether it can be changed to be a command-line argument the user provides instead of it being determined by inspecting the codepages of the content.
api-spec-converter (98Mb) is used by the Swagger node to handle the different versions of the OpenAPI spec. swagger-js-codegen-formdata (15Mb) is the core functionality for the Swagger generator - can't avoid that.
jimp (37Mb) is used by all nodes to check the size of the icon, and to resize it if needed. Personally, I think we can do without this code and just use the image provided. If we keep it, it needs to be updated to reflect we support svg, font-awesome and the images can be any size as long as they have a 1:2 ratio.
javascript-obfuscator (25Mb) is a lot of code for functionality I don't really care for. Obfuscation doesn't provide any real security and is easily undone.
Another option to consider is making them separate nodegen tools - rather than all bundled into the one. That'll minimise the overhead for users who are only interested in one or other of the modes.
The text was updated successfully, but these errors were encountered:
The main offender is cldr (198Mb) - which is used by the WoT node to determine the text direction of some part of text. I don't know enough about the WoT code to know how important this is and whether it can be changed to be a command-line argument the user provides instead of it being determined by inspecting the codepages of the content.
It is overkill that using cldr to just find a text direction from a locale ID... I'll update to use other smaller npm module (for example, rtl-detect).
An
npm install
of node-red-nodegen results in 265Mb of node_modules. If you npm install the repository (so devDependencies are included) it's over 650Mb.I would like to see if we can reduce this overhead. This issue is a summary of what is using the space - and to explore what we can do about it.
Here are the current dependencies and how much they contribute to node_modules:
The main offender is
cldr
(198Mb) - which is used by the WoT node to determine the text direction of some part of text. I don't know enough about the WoT code to know how important this is and whether it can be changed to be a command-line argument the user provides instead of it being determined by inspecting the codepages of the content.api-spec-converter
(98Mb) is used by the Swagger node to handle the different versions of the OpenAPI spec.swagger-js-codegen-formdata
(15Mb) is the core functionality for the Swagger generator - can't avoid that.jimp
(37Mb) is used by all nodes to check the size of the icon, and to resize it if needed. Personally, I think we can do without this code and just use the image provided. If we keep it, it needs to be updated to reflect we support svg, font-awesome and the images can be any size as long as they have a 1:2 ratio.javascript-obfuscator
(25Mb) is a lot of code for functionality I don't really care for. Obfuscation doesn't provide any real security and is easily undone.Another option to consider is making them separate nodegen tools - rather than all bundled into the one. That'll minimise the overhead for users who are only interested in one or other of the modes.
The text was updated successfully, but these errors were encountered: