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
Currently, there's a local "fixer.js" containing the value-inference code.
If this was put in a separate module, other interfaces to this code could be written.
Normalization of all package data is one application.
Another application could be to make a "class" that takes package data in its constructor, than has methods to get the inferred/fixed value for any field.
This is not as trivial to implement as it may seem, because creating the right value for one field could require having the right value for another beforehand.
For example getBugsURL would have to call getRepositoryField. This in itself is not hard to implement, but it would make the full normalization less efficient. Internally, it wouldn't be one sweep anymore. A potential approach would be to memoize the methods (i.e. cache their return value).
darcyclarke
changed the title
Move value-inference functions into separate module?
[QUSTION] Move value-inference functions into separate module?
Jul 28, 2022
Currently, there's a local "fixer.js" containing the value-inference code.
If this was put in a separate module, other interfaces to this code could be written.
Normalization of all package data is one application.
Another application could be to make a "class" that takes package data in its constructor, than has methods to get the inferred/fixed value for any field.
Sometimes normalizing all fields isn't needed. For example, in the code for
npm bugs
command.I do consider this a "nice to have". Far from critical.
The text was updated successfully, but these errors were encountered: