No need for X amount of different Node.js version to all run the linting
as part of their CI rutine. Easier to just run that once, completely
separate from the unit tests.
Removes running Node.js 10 & 12 from Travis CI as we do that with
GitHub Actions as well.
The only reason we still keep Node.js 8 running on Travis CI is due to
the browser usage testing we've setup, with encrypted secrets and all.
Ideally we'd move those browser tests to run via GitHub Actions for
consistency with the rest of our tests, but postponing that work
for now as it's not critical.
As seen from the test run log:
```
$ deno test --allow-net=deno.land test/module-systems/deno-test.ts
Compile file:///home/runner/work/mustache.js/mustache.js/.deno.test.ts
Download deno.land/std@v0.51.0/testing/asserts.ts
Warning std versions prefixed with 'v' were deprecated recently. Please change your import to deno.land/std@0.51.0/testing/asserts.ts (at deno.land/std@v0.51.0/testing/asserts.ts)
error: Uncaught Error: Import 'deno.land/std@v0.51.0/testing/asserts.ts' failed: 404 Not Found
at unwrapResponse ($deno$/ops/dispatch_json.ts:43:11)
at Object.sendAsync ($deno$/ops/dispatch_json.ts:98:10)
at async processImports ($deno$/compiler.ts:736:23)
```
The `render` argument passed to a `function (text, render)` lambda function was not accounting for custom tags or other configuration. This issue has been fixed and a regression test has been added for this case.
If an object is provided for what used to be the `tags` argument instead of an array, then the object is treated as a "config" object. A config object can have a `tags` attribute which behaves the same as the `tags` argument, and it can also optionally have an `escape` argument that is used for providing a custom escape function for that render call. The rationale for this addition is that providing an escape function here, when rendering a template, is a safer pattern for specifying an escape function than modifying the global mustache.escape attribute when a project may need to use mustache to render more than just one kind of content, e.g. both HTML and Latex templates in the same project.
Windows shell does not recognize 'single quotes' the same way as bash. The 'single quotes' in the build command have been changed to "double quotes" instead.
These changes optimizes the performance of escaping number
values, by not passing them through the ordinary HTML escaping
that is done on string values.
In the spirit of keeping the public API of mustache.js as small as
possible for maintainence reasons, the undocumented and un-tested
`.to_html()` method is removed.
The functionality involved, where it can rather invoke an optional
function provided with the result of `.render()`, instead of returning
it as a string like `.render()` does, is something that using projects
very easily can do themselfs -- it does not have to be provided by
mustache.js.
Blooper introduced when making the usage examples in README.md
more modern a couple of days ago, where the example fetching the
mustache template over HTTP, didn't in fact use the fetched template.
Since TypeScript usage has exploded the last years but this is
package is written in JavaScript, we might at least reference
the external DefinitelyTyped package @types/mustache that has
a somewhat up-to-date set of type definitions for most of the package.
Primarily because the these sections were very given a lot
of attention, high up in the README, where ideally usage and
basic syntax should have priority.
More and more of the community seems to be encouraging use of
zero-dependency packages. We might as well point that out early
on in our README since that's how mustache.js always has been
and planned to be going forward.
When recently updating the usage examples in the README,
it blooper was introduced where `response.text()` was forgotten
when retrieving a mustache template with `window.fetch()`.
Historically jQuery was seen as an absolute minimal to create
anything with JavaScript. That time has past now that relatively
modern browsers has excellent support for a lot of the things
jQuery helped us with -- at least with the trivial examples shown
in our README.
Therefore removing jQuery usage from our examples as that should
not be a necessary dependency in these examples.
These changes allows the internal template cache to
be customised, either by disabling it complete or
providing a custom implementation of how templates
are cached.
The git pre-commit hook we've been using the last years to keeping
.version found in `package.json` in sync with the .version field
exposed by the source code, did not handle version numbers often
used for pre-relases like `beta | new` etc.
Therefore making sure it searches for versions that also contains
characters, not only numbers separated by dots. That will make sure
the following is also seen as valid versions: `3.2.0-beta.0`,
whereas before the `-beta` part would cause trouble.
This changes the pre-commit hook that we've used for years to keep the
version value found in `package.json` in sync with the one in
`mustache.js`, to change `mustache.mjs` instead since that's where the
source code lives now.
With the introduction of a build step, where we take the source in .mjs
and build it into .js for non-ES Module systems, it's very important
that we remember to keep those two in sync.
That's what the CI job created in these changes ensure;
1. Run the build script
2. See if there are any pending git changes as a result
As long as there are no pending git changes, we're all fine and dandy,
or else we need to run the `npm run build` and commit the changes.
To ensure the ES module and source exposed by this package is compatible
with Deno going forward.
Added benefit is we get some sanity checks of the source code for free
due to Deno's built-in TypeScript compiler getting angry if it sees
things that does not make sense, in terms of missing function arguments
and so on.
Minor adjustments needed to make the TypeScript compiler
that is built into Deno, be happy with how mustache.js'
ES module source looks in terms of function parameters
passed and object mutability.
Refs https://github.com/phillipj/mustache.js/pull/1
By making the main source code an ES module placed in `mustache.mjs`,
what used to be in `mustache.js` is now built based off of the ES module
source inside `mustache.mjs`.
This is done primarily to avoid breaking existing projects already using
mustache.js, by keeping the UMD-version in `mustache.js` part of the git
repository in addition to the minified version in `mustache.min.js`.
After experiment with several compilers;
- Babel
- TypeScript
- Rollup
and examining their build output, [Rollup](https://rollupjs.org/) was chosen
because of the UMD output it creates which closely resembles what we've
historically had in the previous `mustache.js` source code.
The contents of `.js | .min.js` files has been generated by running
the following npm script:
```
$ npm run build
```
Also change linting w/eslint to target the `.mjs` file, since the output
of rollup that ends up in the old `mustache.js` file is not sensible to
do linting on.
As part of transition the source code to be a proper plain ES module,
we're removing the handcrafted UMD wrapper around the source code.
This means the UMD wrapper will have to come from elsewhere; a build
step introduced later.
In an effort of moving with recent changes in Node.js and its built-in
support for ES modules, we're making the main source code reside inside
`mustache.mjs`. This will also allow Deno users to use this package as
an ES module directly by importing `mustache.mjs`.
An ES3 / UMD version of the source code is still planned to exist in
`mustache.js`, but will involve a build step to transform the ES module
source into a plain .js version.
By renaming the file *before* changing any contents, git will
recognise the file has been renamed and therefore allows us to see all
historical changes to the old .js source code with the `--follow` argument:
```
$ git log --follow -- mustache.mjs
```
Without ensuring git sees this is a file rename, we will in practise
loose the old source code's history, or at least make it quite weird
and less intuitive to find. That's not fair to the historical
contributors and in general getting hold of a well documented log of
changes to a file in git, is extremely valuable in those few scenarios
where it's *really* needed.
This is a precursor to introducing a build step that will change what
we expose from this package. Better off writing some tests to verify
existing projects with different module systems continue to work as
expected.
This is a precursor to introducing a build step that will change what
we expose from this package. Better off writing some tests to verify
existing projects with different module systems continue to work as
expected.
This is a precursor to introducing a build step that will change what
we expose from this package. Better off writing some tests to verify
existing projects with different module systems continue to work as
expected.
Phillip Johnsen
Sophie Kirschner
Pierre Carru
Frieder Bluemle
urain39
Tim Gates
Ricardo Aielo
Andrew Leedham
Eamonn O'Brien-Strain
Vincent LE GOFF