Me again. No worries, no bugs, but I've discovered that my IDE of choice, Atom, uses Electron which at the version in use, bakes in an older version of Node so it errs with the error I mentioned that the engines fix was to warn about (engines isn't the problem here though, as a user can install comment-parser with a higher Node version by the command line, but Atom will still unfortunately use the older baked-in Node version regardless).
So I am wondering if we could temporarily re-export the nested exports we need from the index file, perhaps renaming the exports to suggest they were only going to be temporarily available from that location?
We need:
/util
/primitives
comment-parser/parser/tokenizers/description
comment-parser/parser/tokenizers/name
comment-parser/parser/tokenizers/tag
comment-parser/parser/tokenizers/type
...and I think we might not need to re-export the first two as they should be safe even with the older versions because they do not have a wildcard in the exports (the errors I've seen so far related to no. 3).
So that would be 4 files (our projects need only the default exports from the last 3, but for the description tokenizer we need its default and its named getJoiner export).
Hi,
Me again. No worries, no bugs, but I've discovered that my IDE of choice, Atom, uses Electron which at the version in use, bakes in an older version of Node so it errs with the error I mentioned that the
engines
fix was to warn about (engines
isn't the problem here though, as a user can installcomment-parser
with a higher Node version by the command line, but Atom will still unfortunately use the older baked-in Node version regardless).So I am wondering if we could temporarily re-export the nested exports we need from the index file, perhaps renaming the exports to suggest they were only going to be temporarily available from that location?
We need:
/util
/primitives
comment-parser/parser/tokenizers/description
comment-parser/parser/tokenizers/name
comment-parser/parser/tokenizers/tag
comment-parser/parser/tokenizers/type
...and I think we might not need to re-export the first two as they should be safe even with the older versions because they do not have a wildcard in the
exports
(the errors I've seen so far related to no. 3).So that would be 4 files (our projects need only the default exports from the last 3, but for the
description
tokenizer we need its default and its namedgetJoiner
export).