v1.x.x #2
Open
v1.x.x #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We want to be able to test various configuration scenarios to ensure that the loader works in different setups and different environments. A _very_ basic test framework was created to allow a set of example configurations to be tested, and these are build against both target:node (and tested in ndoe) and target:web (tested via browser-run) Notable changes: * Templates are precompiled where possible by default. * When the loader detects that it is not the first loader in the chain it will fallback to non-precompiled templates. * When non-compiled templates are in use the non-SLIM version of the runtime will be bundled. * Bundling for target:web now works as expected.
added 17 commits
March 4, 2018 18:28
Use the schema-utils package to perform some basic schema validation of the options object
Add a new 'configure' loader option that points to the location of a
module that exports a single (default) function that will be used to
make modifications to the Environment[1] instance that is used to render
any loaded templates.
For example adding:
```
options: {
configure: 'path/to/nunjucks.config.js'
}
```
might cause the follow configure func to add filters/globals:
```
export default function(env) {
env.addFilter(...);
env.addGlobal(...);
}
```
[1] https://mozilla.github.io/nunjucks/api.html#environment
Enable configuring the "tags" (the characters used as the start/end markers in templates. The tags option needs to be configured in the environment at compile time. We support both precompiling and runtime compiling so need to ensure the options are passed to all instances of the environment.
Add test to ensure that autoescape is always set by default and enable overriding it from loader options.
throwOnUndefined can be used to raise errors for any undefined variables in templates (rather than the default of ignoring them). This adds the loader option to configure this.
trimBlocks can be set to remove trailing newlines from a block/tag
the lstripBlocks option can be set to strip leading whitespace from block lines. It's disabled by default.
Show how to use the configure function to set global variables on the environment. Since this test is basically the same as the custom filter test we also use a different module syntax to try and catch any issues with how the configure function/module is imported by the loader
import blocks should be discovered from includePaths
precompile: 'auto' - this is the default value, it will try it's best to precopmile templates and bundle the 'slim' version of the nunjucks runtime. Most of the time this is what you want. precompile: true - if this is enabled it will throw an error during webpack-time if it is unable to precompile templates and use slim. This option is useful to protect against accidently introducing webpack configuration that triggers the non-precompiled bundling which may be important for browser bundles precompile: false - if this option is set, precompilation is never attempted and the full runtime is bundled. The only reason I can think of that you might want this option is if you want to post process nunjucks with some kind of loader that expects the raw source.
If you are attempting to import a njk template from a node_module ie
```
{% from "my-module/x.njk" import y %}
```
then the parentPath given to the template Loader would be a relative
path and not the expected absolute path required to reference the
template.
To work around this, we pass the expected name when compiling the
compiled ahead of time so the paths match.
We want to enable code coverage reporting to highlight any areas that are not getting covered. It's tricky to test some of the exceptions that get raised with the current test setup so we ignore most of edge case exceptions since the output is a fatal bail anyway.
To ensure consistancy between precompiled/runtime-compiled templates the root template code and Loader were refactored so the ?mode=compile always returns the expected src object with the correct env set. This resovles issues with mixing compiled and uncompiled templates.
Use the test-with-coverage script to get coverage warning via travis
added 2 commits
March 4, 2018 20:11
Bit of help for when you want to only run a single test by number. ``` TEST_FOCUS=013 npm test ``` to just build/run test 013
Add an example of adding a filter when precompile:false to prevent regressions. The filter is an example of using the jmespath library to allow reshaping data objects in a declarative way.
|
Release Date? Thanks |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
We want this module to have a decent set of features and full test coverage so we can we happy with using it in production build tools and so we have a base to build on.
will fallback to non-precompiled templates.
runtime will be bundled.
includePathsoption should allow specifying paths to njk includesconfigvsconfigureoption)What is not being support yet
How to review
Code review, check tests and coverage, try to use it based on the info in the README