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
Improve performance by directly constructing AST from buffer (#5391)
* Use consistent module resolution
* Fix number literal casing
* Store esTreeNode of import expression argument on ImportExpression
* Move ReadString type
* Pre-generate keys for iteration
* Separate parsing and node construction
* Add missing AST nodes and improve some names
* Add additional Node keys and adapt some logic
This prepares for the new buffer parsing
* Initial version of bufferParsers
TODO: Special logic in parseNode of some nodes
* Use absolute positions
This should make future template logic easier
* Move annotation flags to the annotated nodes
* Move invalid annotation handling to Program
* Improve expression
* Make parse and panic errors proper nodes
* Directly consume buffer
We still need to update generate-buffer-parsers
with the provided changes.
* Provide correct scopes to nodes
* Add post-processing steps
* Move static flag to first position
* Add remaining customizations
* Create new perf script that measures against node_modules rollup
* Run form tests twice to improve coverage
The second run uses the cache
* Avoid unnecessary cache generation
* Do not generate cache on CLI unless requested
* Keep AST if cache is not explicitly disabled
* Test panic errors for synchronous parsing
* Do not run the leak test locally on npm test
This does not work on non-x86 architectures
* Test custom AST
* Remove unnecessary conditional
* Add descriptions for all relevant test categories
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+26
Original file line number
Diff line number
Diff line change
@@ -56,6 +56,32 @@ npm run test:quick
56
56
57
57
Note that this does not run the browser tests and a few CLI tests will fail.
58
58
59
+
### How to write tests
60
+
61
+
For any new feature or bug fix, sufficient test coverage is crucial.
62
+
63
+
Note that Rollup does not really have unit tests, only the external APIs are tested with the full Rollup build. While this may seem unusual, the tests are still very stable and fast. This provides us with the ability to perform major refactorings of the code base while ensuring full compatibility with the previous versions.
64
+
65
+
There are different test categories. Most of these tests are directory-based where you have a directory with a `_config.js` file that contains the test description and configuration and several code files. See [/test/types.d.ts](./test/types.d.ts) for a full list of available test configuration options for all directory based test types. By default, unless specified otherwise, the `main.js` file is the entry point for the test. To run the tests in an IDE, configure a ["Mocha" compatible test runner](https://mochajs.org/#editor-plugins) that uses `test/test.js` as the entry point.
66
+
67
+
-**[`test/function`](./test/function/samples)**: These tests bundle to CommonJS and then run the entry point provided by `main.js`. The `assert` function from `node:assert` is injected as a global variable, so you can make inline assertions in the code. You can also use the `exports` configuration key to make assertions on the exported values. These are very stable and meaningful tests and should be your first choice for new tests.
68
+
- For regression testing when Rollup produces invalid code or crashes
69
+
- For testing plugin interactions. To do so, import `node:assert` in your `_config.js` file and make assertions in your plugin hooks as needed.
70
+
- For testing expected bundling errors, warnings and logs (use the `error`, `generateError`, `warnings` and `logs` configuration keys)
71
+
- For asserting on the generated bundle object (use the `bundle` configuration key)
72
+
-**[`test/form`](./test/form/samples)**: These tests bundle to all output formats and do not run the code. They compare the bundled code against an `_expected` directory that contains the output for all formats. If the format is not important, you can specify an `_expected.js` file instead, which will be compared against the output when bundling to ES module format.
73
+
- For testing tree-shaking
74
+
- For testing code that does not run on all supported NodeJS platforms
75
+
-**[`test/chunking-form`](./test/chunking-form/samples)**: Similar to the `form` tests, these tests support multiple output files and assets. Instead of a single file, there is a directory for each output format.
76
+
-**[`test/cli`](./test/cli/samples)**: These tests run the Rollup CLI with a given configuration. They can compare the generated files against provided files and make assertions on stderr output. They can also optionally run the generated files.
77
+
-**[`test/watch`](./test/watch)**: Test that watch mode works as expected. These tests are actually in the `index.js` file and only use the `samples` directory for input files.
78
+
-**[`test/browser`](./test/browser/samples)**: These tests bundle with the browser build of Rollup. They compare the output to an `_expected` directory and allow to make assertions on bundling errors. Note that you need to provide all input files via plugins.
79
+
-**[`test/sourcemaps`](./test/sourcemaps/samples)**: Tests to make assertions on the generated sourcemaps.
80
+
-**[`test/incremental`](./test/incremental)**: For testing the caching behaviour of Rollup. As these tests need to run Rollup more than once, it was not easily possible to implement them as directory-based tests.
81
+
-**[`test/file-hashes`](./test/file-hashes/samples)**: Relevant for testing that different outputs have different file hashes. With the new hashing algorithm, these tests are not as important as they used to be and are kept mostly for historical reasons.
82
+
-**[`test/hooks`](./test/hooks)**: Do not add new tests here. These tests were the original tests for the plugin interface. For new tests, `function` tests are preferred as they are much easier to maintain.
83
+
-**[`test/misc`](./test/misc)**: General tests that do not fit into the other categories.
0 commit comments