- long logs of output or long configs are hard on the eyes and make it
difficult to read through issues as they just take up so much space
- so it would be better, in my opinion, to hide them by default with
spoiler tags, which can be opened up when further investigation is
warranted
- some issue authors have already used this pattern, this just brings
it to the template itself so everyone (hopefully) starts using it
- replace the version list with a copy+paste this envinfo command,
copy back the output
- uses a modified, shortened variant of something being used
successfully downstream in TSDX: 349f299976
- this should make reporting versions zero-effort and thereby
significantly decrease non-reporting by making the hard thing easy
- personally have experienced issues that didn't report but version
was very relevant to the issue
- also some folks report "latest" or used carets, which lack posterity
or are confusing
- previously, declarationDir was set to cwd if useTsconfigDeclarationDir
wasn't true, however, declarations aren't output to cwd, but to
Rollup's output destination, so this was incorrect
- instead, don't set declarationDir, which defaults it to outDir,
which is currently set to a placeholder
- previously, it rewrote declarations to output to Rollup's dest
from cwd, now rewrite from outDir placeholder instead
- and add a rewrite of sources to match relative path from Rollup's
output dest instead of outDir placeholder
- also change the one line in the docs that says it'll be
`process.cwd()`; every other reference says it'll be the output dest
* stop roll() from failing if the new cache has no files
Today I stumbled upon an error where it would fail when the cache folder was not present
```(typescript) Error: ENOENT: no such file or directory, rename 'REDACTED\node_modules\.cache\rollup-plugin-typescript2/rpt2_759e2fd8d3f20c1a0805faf5404af6bea36632fd/code/cache_' -> 'REDACTED\node_modules\.cache\rollup-plugin-typescript2/rpt2_759e2fd8d3f20c1a0805faf5404af6bea36632fd/code/cache'```
This PR fixes it by checking its existence before trying to rename it
* use existsSync instead of fs.existsSync
* use renameSync instead of fs.renameSync
- so remove that reference to objectHashIgnoreUnknownHack
- also be more specific about what cases objectHashIgnoreUnknownHack
might be needed for
- asyncgeneratorfunctions are still one off the top of my head, but
there are certainly others it just won't know about, including
future syntaxes
- object-hash v2.0.2 adds/fixes support for async functions
- object-hash v2 has no breaking changes, just drops testing of
Node < 6
- Node 5 was EOL April 2018, and on top of that Node 6
was EOL April 2019, and Node 8 was EOL December 2019, so this is
still more tested support than is necessary
- objectHashIgnoreUnknownHack isn't useful for its original purpose to
workaround this, but is still useful for other types of
objects/syntaxes that object-hash may not handle yet
(e.g. async generator functions), so leave the hack in
- might be good to add a warning though? so that those who used this
option for async/await can upgrade and remove it (and have a
stable cache again)
