* refactor: split out a common typecheckFile func
- this is used in 3 places and going to be more for the code I'm adding
to fix type-only imports
- so DRY it up and standardize the functionality too
- some places had `noErrors = false` in one place while others had
it in another
- same for `printDiagnostics`
- but the ordering actually doesn't matter, so just keep it
consistent and the same
- and then can split a common function that does both out
- technically, now getDiagnostics is _only_ used in typecheckFile, so
I could link to the two together, but I'm refactoring that one up
a little
- but this a good, small example of how refactoring one part of a
codebase can make it easier to identify more similar pieces and then
refactor even more
* fix lint error on shadowed name
* refactor(cache): simplify `clean` method
- `cache().clean()` is only called during instantiation in `options`, so we can instead just call it inside of the constructor
- there is no need to call `this.init()` in `clean` as it's only used in the constructor anyway, which already calls `this.init()`
- and if `noCache` is `true`, `init` is basically a no-op too
- so technically we don't need to call `init` _at all_ if `noCache`, but that's a larger refactor that I'm splitting into a separate commit/PR
- now that `clean` is just one conditional, we can invert it and return early instead
- it's also not necessary and less efficient to call `emptyDir` before `remove`; `remove` will unlink all the contents anyway
- docs here: 0220eac966/docs/remove-sync.md
- though this also just normal FS behavior
- IMO, it's also not necessary to check if it's a directory, we can `remove` it either way
- and not necessary to log out if we _don't_ clean it
- then also just simplify the logic to use a `filter` instead of a nested `if`
- which we already do in several places, so this follows existing code style
* undo dir and not clean log removal
- as requested in code review, will go with a safety-first operating assumption
- as such, with safety as modus operandus, make the logging more detailed in these scenarios, since they're not supposed to happen
- and don't check code coverage on these as they're not supposed to happen in normal usage
- these should run through the same `filter` as runs in `transform` etc
- prior to this, the plugin `exclude` would filter files in
`transform`, meaning no JS would be output for them, but would still
output declarations for these very same files that no JS was
produced for
- (this would only happen if one were using an `include` glob or
something that made the file appear twice, i.e. once by Rollup
in `transform` and once in `parsedConfig.fileNames`)
- this change makes it so the plugin `exclude` affects both JS
and DTS output equivalently
- it was very confusing when it didn't, and users relied on setting
different `tsconfig` `exclude`s to workaround this (as a
`tsconfig` `exclude` would make the file not appear in
`parsedConfig.fileNames`)
- this checks if any of the files in `parsedConfig.fileNames` are _not_
in `allImportedFiles`, but all the files in `parsedConfig.fileNames`
are explicitly added in the `options` hook on line 98
- so this is redundant / dead code; the check will never be true
- this can be considered a remnant of an old bug as an old commit fixed
a bug with `allImportedFiles` after it was released:
f24359e668
- previously, while errors would be printed, the flag for `noErrors` was
not set to `false`, and so there would be no yellow warning about
errors
- this is mostly just fixing asymmetric UX, but personally, I actually
have missed this error before myself, so maybe this will help
alleviate that
- the snapshot is set above, so no need to get it
- also the snapshot from above is used below already, so this doesn't
seem to be intentional
- it originates from 2d330640316894752bae5ae64d94bc90652e4564 which
similarly doesn't seem intentional
- basically, general format is:
```ts
import x from "external-dep"
import y from "./internal-dep"
```
- so external deps, new line, then internal/local deps
- with some further sorting within there, like trying to keep Node
built-ins (e.g. `path`) at the top half of externals, then core deps
like `typescript`, then any other external deps
- and similar for internal deps -- core internals at the top half of
internals, then any other internal deps
- just to keep things consistent between files -- makes the top
easier to read through when it's similar between files
- also makes it easier for contributors to understand where to put
imports, as there's a sorting already there
- this is how I generally sort my imports and how I wrote most of the
unit test suite's imports as well
- there is automation for this that we should probably add once TSLint
is replaced here; some previous art:
- https://github.com/trivago/prettier-plugin-sort-imports
- https://github.com/lydell/eslint-plugin-simple-import-sort/
- Older:
- https://github.com/renke/import-sort/tree/master/packages/import-sort-style-module
- https://github.com/mcdougal/js-isort
- inspired by Python's `isort` ofc
- when using rpt2 as a configPlugin, there is no Rollup `output`, so it
will be `undefined`
- when `declarationMap: true` in `tsconfig`, this block of code is
called as a workaround due to the placeholder dir we must use for
output -- but, in this case, it errors out, since the
`declarationDir` is `undefined`
- `path.relative` needs a `string` as a arg, not `undefined`
- so skip this transformation entirely when there's no `output`, as
it doesn't need to be done in that case anyway
- this transformation code happens to have been written by me 2
years ago too, so I had fixed one bug with that but created
a different bug 😅 (fortunately one that only I have stumbled upon)
- a few `if (cond) { big block } return` could be inverted to
`if (!cond) return` then the block unindented instead
- generally speaking, this makes it a lot more readable (less
indentation, etc) and follows the existing code style in much of the
codebase, where it's a few quick one-line ifs and then just the rest
of the code
- shorten the resolvedFileName conditional by using optional chaining
- prefer the simpler `x?.y` over the older `x && x.y` syntax
- add a `resolved` variable for less repetition of the whole statement
- add a comment to the `pathNormalize` line about why it's used in that
one place and link to the longer description in the PR as well
- shorten comment about `useTsconfigDeclarationDir` so it doesn't take
up so much space or look so important as a result
- and it's easier to read this way and I made the explanation less
verbose and quicker to read too
- remove the `else` there and just add an early return instead, similar
to the inverted conditionals above
- similarly makes it less unindented, more readable etc
* - fix for vue declaration file names
* fix: use .d.ts instead of .vue.d.ts for Vue declarations
- `.vue.d.ts` was recommended by the `rollup-plugin-vue` maintainers
back when this code was originally written, but apparently it causes
problems with some imports
- plain `.d.ts` seems to work fine according to users
- and plain is the standard in TS too I believe
Co-authored-by: ezolenko <zolenkoe@gmail.com>
- _.endsWith -> String.endsWith
- _.concat -> Array.concat
- _.each -> Array.forEach
- _.filter -> Array.filter
- _.map -> Array.map
- _.some -> Array.some
- _.has -> `key in Object`
- _.defaults -> Object.assign
- _.get -> `?.` and `??` (optional chaining and nullish coalescing)
- refactor: replace fairly complicated `expandIncludeWithDirs` func to
just use a few simple `forEach`s
- not as FP anymore, more imperative, but much simpler to read IMO
- refactor: add a `getDiagnostics` helper to DRY up some code
- also aids readability IMO
- a few places are still using lodash, but this paves the way toward
removing it or replacing it with much smaller individual deps
- _.compact still used because Array.filter heavily complicates the
type-checking currently
- _.isFunction still used because while it's a one-liner natively,
need to import a function in several places
- also the package `lodash.isFunction` is lodash v3 and quite
different from the v4 implementation, so couldn't replace with it
unfortunately
- _.merge is a deep merge, so there's no native version of this
- but we may remove deep merges entirely in the future (as tsconfig
doesn't quite perform a deep merge), or could replace this with a
smaller `lodash.merge` package or similar
- see also https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore
- at least as of TS 2.1: https://www.typescriptlang.org/docs/handbook/utility-types.html#partialtype
- we have a peerDep on TS >=2.4, so should definitely be compatible
- and TS is on ~4.6 at this point, so that's _really_ old
- remove the file and the declarations and declaration maps
- don't rebuild as that's usually done as a separate commit
- this was introduced in v4.1.0 of @rollup/pluginutils:
https://github.com/rollup/plugins/blob/master/packages/pluginutils/CHANGELOG.md#v410
- this is the same as the code in `normalize.ts` but it uses constants
from Node and is used by multiple Rollup plugins, so just helps with
standardization
- also less code and types to ship in the bundle!
- removed the dist files for `normalize` as well, but didn't do a build
in this commit as those are usually done in separate commits
On Windows the normalized paths in resolveId end up in POSIX format.
This cause rollup to treat the returned path as a new piece of content.
This in turn results in duplicate output for references across entry points.
Fixed by normalizing the path to use host OS separators before returning.
- 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
