mirror of https://github.com/ezolenko/rollup-plugin-typescript2.git synced 2025-12-08 19:06:16 +00:00

refactor(cache): simplify noCache condition (#362 )

- if there is no cache, we don't need to do any operations on a cache at all, so we can just totally skip all the cache operations and return early
  - this should be a perf improvement, at the very least on memory usage, as lots of stuff isn't created or processed now
    - this may make `clean: true` a more optimal choice for smaller projects, as the FS usage when writing to cache may be slower than the small amount of compilation and type-checking required in small projects

- to start, from the constructor, the only necessary piece when `noCache` is the dependency tree
  - this is needed for `walkTree` and `setDependency` to function, but otherwise is unused when `noCache`
    - this _might_ be able to be further optimized to remove the graph entirely when `noCache`, but that is saved for potential future work and not part of this commit
  - so, we can just move the tree creation further up in the constructor as its previous ordering within the constructor does not actually matter
  - once this is done, we can just early return when `noCache` instead of doing all the cache-related actions, since they're not neeeded when there is no cache
    - no need to set `cacheDir` or any hashes etc since they're not used
      - note that `clean` only uses `cachePrefix` and `cacheRoot`, which are already set, and does not use `cacheDir`
    - no need to `init` the cache as it's not used
      - also slightly change the ordering to move `init` right after its prereqs are done, i.e. setting `cacheDir`, `hashOptions`, etc
        - just keeps with the flow instead of calling it in the middle of the ambient type processing
    - no need to check ambient types as that is only used for cache invalidation (marking things dirty), which is not used when there is no cache
      - note that `isDirty` is literally never called when `noCache`

- from there, since we don't call `checkAmbientTypes` or `init` when `noCache` (the constructor is the only place they are called and they are both `private`), we can entirely remove their `noCache` branches
  - fairly simple for `checkAmbientTypes`, we just remove the tiny if block that sets `ambientTypesDirty`, as, well, "dirty" isn't used when there is no cache
  - for `init`, this means we can entirely remove the creation of `NoCache`, which isn't needed when there is no cache
    - that means we can also remove the implementation and tests for `NoCache`
      - and the reference to it in `CONTRIBUTING.md`

- in `done`, we can also simply skip rolling caches and early return when there is no cache

- the only other tiny change is the non-null assertions for `ambientTypes` and `cacheDir`
  - this matches the existing, simplifying non-null assertions for all the caches, so I did not workaround that
    - _could_ set a default of an empty array for `ambientTypes` etc to workaround this, but thought it better to match existing code style and not add new things
  - this also matches the behavior, as while `ambientTypes` and `cacheDir` could be `null`, this is only if there is no cache, in which case, they are never used

2022-06-24 10:38:49 -06:00

5.7 KiB

Raw Blame History

Contributing

Reporting bugs

Report any bugs in the GitHub Issue Tracker.

Please follow the issue template as closely as possible:

Attach your tsconfig.json, package.json (for versions of dependencies), rollup.config.js, and any other pieces of your environment that could influence module resolution, ambient types, and TS compilation.

Some additional debugging steps you can take to help diagnose the issue:

Attach plugin output with verbosity option set to 3 (this will list all files being transpiled and their imports).
If it makes sense, check if running tsc directly produces similar results.
Check if you get the same problem with clean option set to true (might indicate a bug in the cache).
Check if the problem is reproducible after running npm prune to clear any rogue types from node_modules (by default TS grabs all ambient types).

Developing

Use the standard GitHub process of forking, making a branch, creating a PR when ready, and fixing any failing checks on the PR.

Linting and Style

Use an editor that supports editorconfig, or match the settings from .editorconfig manually.
Fix all linting problems with npm run lint.

Testing

npm test to verify that all tests pass
npm run test:watch to run tests in watch mode while developing
npm run test:coverage to run tests and output a test coverage report

While this repo now has an assortment of unit tests, it still badly needs integration tests with various scenarios and expected outcomes. Test coverage improvements for existing files and untested is needed as well.

Building and Self-Build

One can test changes by doing a self-build; the plugin is part of its own build system.

make changes
run npm run build (uses last released version on npm)
check that you get expected changes in dist
run npm run build-self (uses fresh local build)
check dist for the expected changes
run npm run build-self again to make sure plugin built by new version can still build itself

If build-self breaks at some point, fix the problem and restart from the build step (a known good copy).

Learning the codebase

If you're looking to learn more about the codebase, either to contribute or just to educate yourself, this section contains an outline as well as tips and useful resources.
These docs have been written by contributors who have gone through the process of learning the codebase themselves!

General Overview

Before starting, make sure you're familiar with the README in its entirety, as it describes this plugin's options that make up its API surface.
It can also be useful to review some issues and have a "goal" in mind (especially if you're looking to contribute), so that you can focus on understanding how a certain part of the codebase works.

Can read get-options-overrides as a quick intro to the codebase that dives a bit deeper into the compilerOptions that this plugin forces.
- The TSConfig Reference can be a helpful resource to understand these options.
Get a quick read-through of index (which is actually relatively small), to get a general understanding of this plugin's workflow.
- Rollup's Plugin docs are very helpful to reference as you're going through, especially if you're not familiar with the Rollup Plugin API.

Deeper Dive

Once you have some understanding of the codebase's main workflow, you can start to dive deeper into pieces that require more domain knowledge.
A useful resource as you dive deeper are the unit tests. They're good to look through as you dig into a module to understand how it's used.

From here, you can start to read more of the modules that integrate with the TypeScript API, such as host, parse-tsconfig, check-tsconfig, and maybe how TS is imported in tsproxy and tslib
- A very useful reference here is the TypeScript Wiki, which has two main articles that are the basis for most Compiler integrations:
  - Using the Compiler API
  - Using the Language Service API
  - NOTE: These are fairly short and unfortunately leave a lot to be desired... especially when you consider that this plugin is actually one of the simpler integrations out there.
At this point, you may be ready to read the more complicated bits of index in detail and see how it interacts with the other modules.
- The integration tests [TBD] could be useful to review at this point as well.
Once you're pretty familiar with index, you can dive into some of the cache code in tscache and rollingcache.
And finally, you can see some of the Rollup logging nuances in context and rollupcontext, and then the TS logging nuances in print-diagnostics, and diagnostics-format-host
- While these are necessary to the implementation, they are fairly ancillary to understanding and working with the codebase.

5.7 KiB Raw Blame History